am I the only one fine with using just jQuery and ajax? I've written a chrome extension with 4k lines of code and I never had any problems. Instead of breaking things into separate classes and components, I just put them in separate files or in logical sequence. I'm sure this can get a lot messy with more than one developer but so far my projects, I almost always just use some jQuery library or plugin that does 80% of what I want to do and hack the rest.
Nope, you're not the only one I agree completely. I'm tired of what seems like an endless supply of new, mega-hyped frameworks that seem to provide only marginal improvements.
I'll take the time to learn something new when it is truly groundbreaking but until then I care more about the end product than what was used to make it.
That is pretty much where every frontend dev starts out and then quickly realizes that as your codebase grows and you have different types of data and events firing back and forth, things get unwieldy fast. I'm sure you think your 4k lines of functions across however many files works for you, but I think if you really take the time to learn one of the good JS frameworks, you will be amazed on how much cleaner and robust your code will become.
In all seriousness I typically work with a lot of designers; asking them to update markup in JSX versus HTML is simply not possible. It's not because they can't figure it out but it makes it more difficult for them to quickly test and they typically break JavaScript in many, unexpected ways. While I'm fine with the UI and business logic separation where UI can contain markup _and_ scripting, I don't think the answer is this awkward solution of shoving HTML into the scripting.
This is what worries me. We are using Angular, and my non-technical co-founder knows just enough HTML and CSS that she makes a very useful contribution to our front-end development. Sometimes the contribution is in the form of HTML mockups produced outside of our app that are easy for me to port over, and sometimes it's direct contributions to the codebase. I worry that if I went the React JSX route that it would be much harder for her, or pure designers that we might hire, to meaningfully pitch in.
My understanding was that forgoing JSX would make the situation worse by falling back to imperatively manipulating the (virtual) DOM within your component. If there is a way to have an external, declarative HTML document using React I would be very interested.
This is why I've implemented a prototyping framework at Catalyze that's built with Angular, the same framework we use on the production front-end.
The flow typically looks like this:
1. Create conceptual wireframes
2. Build static UI components (typically in sketch)
- This step helps us define the look and feel of the product before jumping into code. However these are not full page mockups. It's more like an internal UI kit, and for the most part, it's fairly standard across products. So we don't have to update it often.
3. Build the styleguide from the UI kit in Sass (within the framework)
- Again, this is fairly standard so it's mostly templatized. We have an internal UI styleguide that's built already. So most of the changes per product are minimal (they're mostly small tweaks to give each product more character).
4. Build the prototype (within the framework)
- Since we use a template for each new prototype things like routing and more complex Angular concepts are already set up. Because of this designers aren't forced to approach the steep part of the hockey stick. They can stick to the view layer.
Sure you can be productive as a single developer. The problem is when you're handed a project from another single developer-project, and the project is a hot mess of spaghetti jQuery where business logic is intertwined with DOM manipulation.
It's basically impossible to work with unless you've created the code yourself.
Do you have an example of a large web application that uses just jQuery and tries to achieve single-page-application type UI?
I ask because I'm a backend (Django) dev looking at upping my frontend chops (having previously used jQuery and ajax to glue things here and there), and I'm overwhelmed by the choice of frontend frameworks at the moment. I'd love to see how a big jQuery project is set up.
Particularly terrified of making a time investment and finding out that my chosen framework is no longer the hotness of the week. Because, support and community and stable API's count.
One project that I work on has a non-trivial front-end (it’s around 50K lines of code) that has been successfully maintained for quite a few years now. It predates all the current trendy JS frameworks becoming popular, and HTML5 for that matter, so instead it uses jQuery and jQuery UI for the basics, along with a Java applet for some graphical aspects.
Based on that experience, I smile a little when I see people claiming that you can’t build significant web apps without a modern framework. Of course you can. The architecture for the app I mentioned has something close to a traditional MVC structure, uses a simple observer system for keeping everything in sync, and generally follows good modular design practices. Nothing about writing code for a web front end magically breaks all the UI ideas we’ve been using successfully in other environments for decades, and people have used those techniques to build UIs vastly more complicated than any web app ever written.
That all said, it’s also true that as the interactions between different parts of models and the rendering of views becomes more complicated in a UI, writing manual code to update the DOM via jQuery becomes tedious. I thought this article summed up the problem quite nicely with the code snippets and diagrams showing potentially SxR relationships between state and rendering when you manually and directly update the latter, compared with S+R relationships when you isolate each side with a good architecture.
So, I’d say the more interesting question if you’re building a not-small web app is whether you are better off building your own architecture or reusing someone else’s. That has the same trade-offs as any other framework decisions in programming; again there is nothing special about writing a web-based front-end really. On the plus side for a comprehensive framework, you get a lot of basic things much quicker than writing them yourself, and the popular frameworks have huge ecosystems built around them so a lot of not-so-basic things can be had relatively easily as well if you need them. On the minus side, in practice you will forever be constrained to work as the frameworks want, which can become a heavy burden later on if you do need to do things that aren’t a perfect fit, and you are locked into external dependencies with uncertain long-term support.
Something I find interesting about React is that although it’s often compared with big front-end frameworks like Angular, it’s really closer to a library than a framework. Fundamentally, you use React to do exactly one job: manage the rendering and events within a specific part of the DOM. It’s agnostic about where any underlying state comes from, what triggers updates to that state, what you’re doing in response to any events, or what you’re doing anywhere else in the DOM. The entire API for React doesn’t quite fit on a single screen, but a minimal working example only depends on three functions that feature in React’s defined interfaces, and even in real production code you probably won’t use more than a handful.
So if you’re the kind of developer who is concerned about bloat and dependencies but also wants to use good tools instead of reinventing the wheel, a library like React is probably a reasonable compromise between retaining control and long-term flexibility in your code but also automating things you really would waste quite a bit of time on otherwise. I suspect this balance is the main reason why it seems to attract favourable comments from a variety of developers, including those who generally don’t like the heavier frameworks and all that comes with buying into them.
Just by way of completeness, probably the most controversial aspect of React is the way it winds up with its version of HTML templates being embedded directly within the JS code (with some optional but convenient syntax that a preprocessor turns into real JavaScript). You aren’t likely to be getting one person/team designing your mark-up and styling and then having a separate person/team implementing your JS coding if you use React. In this respect it does also come with a degree of lock-in, because transferring those mark-up/template assets to another rendering library or framework later would be a chore. However, that’s somewhat true for most other template-rendering tools you might use as well, because they all tend have their own syntactic quirks, so I’m not sure it’s really worse than other reasonable choices you might make.
So in summary, you certainly can build web apps using manual, direct DOM manipulation via jQuery and the like, but you will also wind up inventing much the same kind of tools that many of these frameworks provide to a degree. There is a balance to be struck between retaining full control and flexibility vs. using good tools, just like any other programming with libraries and frameworks. As for React specifically, it really sits closer to the library end of the spectrum than a lot of modern JS frameworks, so if you do want a modern tool to help with rendering and managing events in your DOM but don’t like the big framework lock-in, it’s probably worth a little of your time to investigate whether it’s a good choice for your project.
> again there is nothing special about writing a web-based front-end really.
I thoroughly disagree. There are a lot of challenges and opportunities with web apps that you do not have in the same way in other UI environments. Having a way of enumerating different states of the application, and jumping between those states (URIs) is just one.
> Having a way of enumerating different states of the application, and jumping between those states (URIs) is just one.
Most web apps treat different routes as different screens, effectively, to use a piece of jargon from a bygone time. A URI is usually just a parameterized screen; IDs in the URI determine which bits of data the app is viewing / editing, no more or less than parameters to a Visual Basic or Delphi form.
There are a lot of challenges and opportunities with web apps that you do not have in the same way in other UI environments.
Can you suggest a few others? I don’t see how the issues that arise with the example you gave are any different to things like parsing command line options or acting on shortcuts in native UIs.
I think part of it has to do with the fact that web development is a very large and diverse field. It's very possible that the types of projects you work on do not require a different approach. For example a web application with a large about of UI elements. Or very specific client requirements. Or a continuous cycle of iterations over time. Or a common structure for a team.
Indeed the old web dev write once, pass it to the client and never see it again has quite a bit of difference in requirements to the large scale robust web application that needs to be able to survive a long period of iteration and maintenance.
