HTML5 vs Objective-C: What are the differences?
Developers describe HTML5 as "5th major revision of the core language of the World Wide Web". HTML5 is a core technology markup language of the Internet used for structuring and presenting content for the World Wide Web. As of October 2014 this is the final and complete fifth revision of the HTML standard of the World Wide Web Consortium (W3C). The previous version, HTML 4, was standardised in 1997. On the other hand, Objective-C is detailed as "The primary programming language you use when writing software for OS X and iOS". Objective-C is a superset of the C programming language and provides object-oriented capabilities and a dynamic runtime. Objective-C inherits the syntax, primitive types, and flow control statements of C and adds syntax for defining classes and methods. It also adds language-level support for object graph management and object literals while providing dynamic typing and binding, deferring many responsibilities until runtime.
HTML5 and Objective-C can be categorized as "Languages" tools.
"New doctype", "Local storage" and "Canvas" are the key factors why developers consider HTML5; whereas "Ios", "Xcode" and "Backed by apple" are the primary reasons why Objective-C is favored.
According to the StackShare community, HTML5 has a broader approval, being mentioned in 3136 company stacks & 3374 developers stacks; compared to Objective-C, which is listed in 844 company stacks and 361 developer stacks.
I want to generate dynamic CSS for each user with an expiry link.
I've created a cloud-based tool (Example - https://www.tablesgenerator.com/) where people can create tables and use them on their website by pasting the HTML generated by the tool.
Now, there are a few styling options needed, which can be done using CSS. As of now, I'm asking the users to copy the CSS and paste it in the "Custom CSS" section, which is a bit hectic work as they need to change the CSS every time if I make any changes to the styling.
So, I'm just wondering if there's a way to generate dynamic CSS for each user with an expiry link.
Currently, I have around 200 users, and what's the best way to do it?
Instead of having the user copy and paste the CSS directly, have them copy and paste the HTML that will include an external CSS file generated and hosted by your application. This will allow you to control when the stylesheet is updated as well as control privileges on who can request the file. Additionally, using a CDN service (e.g. Cloudflare) will allow you to cache the static assets being requested reducing overall server load.
When your server (and optionally CDN) no longer are serving the file, consider the link expired. Unique URLs can be generated using a multitude of methods but maybe consider if there is any benefit to the users if it follows the scheme: yourdomain.com/USERNAME/CUSTOM_NAME.css rather than something like: yourdomain.com/style/SOME-UNIQUE-HASH-1234.css
The best way, as usual, is a "it depends".
Still I would go to something as simple as storing the expire date+the generated css and other metadata in a table. If a user tries to access something that is expired than he's redirected to a specific page. Periodically (like once a day), a janitor process deletes the old data.
Nowadays, everybody is using components to build their frontend and I hardly see someone touching html deeply.
For css framework, choose a utility framework such as Tailwind CSS. It wont look magic to you and wont hide technical specs like magic.
Choose one front-end framework (I recommend react.js or vue.js) for employability and node/express combo for the backend.
I think you scan skip MongoDB for now and focussing on creating web component with Reactjs or Vue, I would also recommend to use TypeScript for type hinting support.
For styling, learn CSS first then upgrade to SASS/SCSS or LESS (pick one as mostly same concept) to make CSS more maintainable.
Also to improve your skill on both sectors, install linters if available. For TypeScipt, there are TSLint and for styling, i think there are Stylint. Linter will help you adapt to make a clean code and understand how other peoples usually styled their code.
- Client-Side: \
The form of our product is a web app because we would also provide a dashboard for displaying data and for some further purpose including data filtering and comparison. Hence, we would definitely use
HTML5for structuring the web,
CSS3for styling the web, and
Reactbecause it is component-based that can keep our front-end code clean and organized. The virtual DOM of
Reactalso provides better efficiency in time when rendering the page. Furthermore,
Reacthas a greater number of users than
Angular, thus have active communities for problem-spotting and problem-solving. We would also incorporate
Bootstrapinto our web app to provide an aesthetic user interface and thus to improve the user experience. The fact that
Boostrapsupports responsive site would also ease our workload if future adaptation for mobiles is needed.
- For our web app frontend, we decided to use
- We chose
ReactJSas our frontend library because its state management would be very handy for our single-page app. React is also component-based, which can help us improve the modularity and extensibility of the project.
- Aside from the standard web technology
CSS, we will use
Bootstrapto style UI components and make our web app responsive to different screen sizes.
Sign up to add or upvote prosMake informed product decisions
Sign up to add or upvote consMake informed product decisions
What is HTML5?
What is Objective-C?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
Basically, the trajectory was we had our iOS app, which started out native, right? It started as a native app, and then we realized you have to go through a review process and it’s slow, and at a very early stage, it made sense for us to make it a wrapped web view. Basically, the app would open, and it would be a web view inside of it that we could iterate on quickly and change very rapidly and not have to wait for app store view process to change it. It wasn’t totally a native experience, but it was as actually a pretty good experience and lasted for a very long time and was up until recently the foundation of our current mobile web experience, which is different from our app situation. So for a long time, basically, our app store iOS Instacart app was a wrapped web view of just our store, a condensed version of our store, which meant that we could add things. We could change sales. We could change the formatting. We could change the UI really fast and not have to worry about the app store review process.
This all changed about a year ago, I would like to say, at which point it became a totally native app. We felt comfortable enough with the product and all the features that we made it a native experience and made it a fully featured app.
At the user interface level, the platform provides a rich visual editor that allows web interfaces to be composed by dragging and dropping. Instead of purely writing HTML, developers use visual widgets. These widgets are wrapped and are easy to reuse just by dragging and dropping without everyone needing to understand how they are built.
Its used for "Food Ordering System" with Mobile Responsive theme.
Custom email template ( Static and dynamic updates)
Cart and checkout modules.
Banners and ads management.
Restaurant listing and website ordering.
It support all the mobile browser compatibility.
While the majority of our stack is now using Swift, we still love Objective-C in many cases, especially low-level software manipulation, where it's just easier. It doesn't hurt that a lot of iOS/OS X Libraries out there are written in it either.
We like to go native with iOS development, and Objective-C has been the only game in town until recent introduction of Swift. We're keeping an eye on Swift, but we aren't giving up on the [old way:to do:things]!
All of our responsive wireframes that are used to build the front end of our clients' sites are built with HTML 5, so we can ensure the most efficient and up to date experience for their customers.
We exclusively use HTML5 instead of XHTML (or even older) HTML-versions. We like the new unity that HTML5 offers and try to keep our code according to the conventions.
We don't leverage much of the new features in HTML5, except for the new Doctype - since it was the latest when we started designing, that's what we used.