Not having a bundled set of widgets is probably an advantage, flexibility wise.
That and load time probably contributed to its success more than anything else.
> and poorly integrated with the rest of the stack.
Yeah, but, so? Maybe I'm too old and curmudgeonly but I preferred it when applications acted like applications and websites acted like websites. Now I have to deal with websites that are half application, without the responsiveness of either and built on a pile of franken-code.
Thing is the browser engines where are not so diligent about CVE's and they are necessary evil, while Java/Flash where optional evil. With the Flash plugin being significantly worse quality than the Java ones.
Truly this is the progress we all hoped to see in computing in 2018.
Back then I was writing applets for science education that would do things like send a mesh to a finite element solver and get the mesh back with stress information.
Back then 2/3 of the code and most of the loading time came from hand-written code to serialize and deserialize data structures. Eg. an applet could have been small and fast loading if serialization was built into the platform.
Java 1.1 added serialization, but it took a long time to get into browsers, Netscape added their own lame serialization scheme, etc... By then the rot was already setting in.
Unless the op, just meant getting "hello world" on the screen from an HTML file, but that is a meaningless metric imo.
Writing a web app in JS is hard, getting the workflow all sorted, and then writing bugfree code. IS more a herculean task than "beginner friendly"
The node, webpack, react stuff is very complicated indeed
"Pretty" is indeed subjective but it's not hard to understand what does it mean for the majority of non-geeks.
JavaFX has been separated from core JDK, to allow for quicker development and integration into other vendors JDKs. Until now the Oracle JDK was the only one supporting JavaFX.
I will take XML over JSON every time I am the one setting the rules.
I much prefer JSON to XML for most scenarios.
NB Not having comments is perhaps the biggest problem I have with JSON when it is used for things like configuration files that will be hand crafted. 99% of the JSON I work with is generated and consumed programmatically so comments aren't really an issue.
I could imagine it would be more complex to build Slack using traditional server-side rendered HTML than building it as an SPA.
Nowadays though you see blogs, CRM systems, etc being built as SPAs, which just makes it more complex to work on them.
However most websites are not webapps and are not needed. A page that is basically just text, a webpage equivalent of a magazine page does not need to be SPA - yet usually is sigh
Generally I would say that SPA are overkill.
In Angular it's trivially easy to bind to an array and have it update. In WPF, it's hard enough that I architect my applications around that one single problem.
Mmm...XAML/WPF has one thing going for it though...you can be assured that a code-base you haven't touched for year will still work :)
Don't forget the constant, unrelenting pressure to keep up with trends or you'll get summarily banned from ever having a developer job again. SPAs got trendy, so naturally everyone had to jump in on it when normal MVC applications work perfectly fine. There's a bit of hyperbole in my previous sentences, but please don't write off the endless articles and forum posts telling people to keep up with X technology because it does influence people.
Like seriously, we're constantly prodding devs into technologies they don't want to get comfortable with, then we're suddenly surprised at the lack of competence.
It’s when they’re hiring for technology instead of skill that I get antsy.
But we recently build a Blazor.net app, and even though it’s new tech, the production time was a lot lower than it would have been, had we used our standard graphql Apollo + Vue approach.
I think something like django might be even more productive, but good luck hiring for that.
Maybe WebAssembly will provide fruitful ground for new, simpler, and more rigorous languages.
I also think that much of modern web apps could be accomplished better with HATEOS apps doing pure server side. But I will allow that my beliefs there are at least partly nostalgic
You might want to abstract over DOM APIs for different reasons, but at their semantic core they are fine.
Sometimes a CRUD form should just be a CRUD form.
The last few maintenance programming jobs I have worked on seem to have been written by people who have used a framework at peak hype cycle, without actually having a good knowledge of the framework.
Job ads never say "writes elegant code with a simple yet effective design". No they want "experience with React, Vue, Rails, Docker, etc".....
Several times I've run into the issue of an API developer misinterpreting "microservice" as "a separate endpoint for direct access to every DB row". Then you find yourself having to make half a dozen API calls for every form, just to keep the UX of the app from becoming a granular nightmare.
If you ran the developer edition of Flash back then, you'd have seen that 99.9% of Flash "crashing" was a totally avoidable, unhandled exception from a third-rate developer.
Let's take a CMS as an example. The "Edit blog post/page" function can be its own SPA avoiding page reload when the post is modified. Managing the list of posts/pages can be another. A page reload in between steps is fine. Nowadays internet speed is fast and latency is pretty low. Browsers are also very efficient and vive caching. If you keep your SPAs small, the user won't see the lag going from one page to another.
Multiple SPAs also allows you to keep things modular. Different teams can own different parts.
Do not however bundle the entire CMS into a single SPA. It will most likely contain a lot of code and resources to load. That will kill performance and slow down development over time.
Rendering the marketing pages of the site -> HTML+CSS
Need to add the tiniest bit of interactivity -> jQuery
Have a "module" of functionality that -> SPA
I disagree. They are whole frameworks taking a completely different approach than jQuery, which is basically just a helper library.
jQuery is useful as a tool for operating within an externally organized application (or otherwise mostly static DOM tree). It simplifies low-level operations like DOM element manipulation.
Frameworks like React or Vue take a top-down, more declarative approach on how the DOM is built and updated. It's in many regards more powerful and more productive, but comes at a certain cost (setup complexity, total page size, certain aspects of performance).
So, which tool is best for your project really depends on the individual use case.
It ain't new and shiny but you can build anything with it.
In fact, today jQuery is used on 97% of websites* while React and Vue are around 0.2%. I imagine that will change over time.
Granted I've only deployed one SPA to prod and that was an Ember application but I'm not feeling the love based on that project.
The new paradigm is using data binding with the latest language features.
Share code between your SPAs, for example, utilities?
What if your SPAs have large dependencies (React, Vue), should every SPA come with their own?
Should every SPA have its own build tools?
What if there's an update to a library, should it be allowed that one SPA runs on an older library?
> Share code between your SPAs, for example, utilities?
We alias a common folder for our utils with webpack which allows all our code to use the same utilities. We actually have two. One for shared frontend and backend, and one for just shared frontend
> What if your SPAs have large dependencies (React, Vue), should every SPA come with their own?
Webpack code splitting is how we split our apps. We also build into multiple bundles to keep bundle size small. That does mean that React does get bundled with each, but if you split thing appropriately, you can potentially save off a few MB with caching each bundle from page to page.
> Should every SPA have its own build tools?
With webpack, you can build all your bundles with one config / command
> What if there's an update to a library, should it be allowed that one SPA runs on an older library?
We have a root package.json for all of our react apps. This means that we don't update a library unless we can update it across the board. It takes more time to test upgrades, but it also means smaller bundles, easier package management and easier maintenance in the long run.
I'm super excited to see WebComponents support. It'll be (and already is if you don't care about IE support) possible to implement this without any frameworks/libraries/etc :)
"Web Components" is a great name IMO.
I have started to think about frontend development as at least two different types and sometimes business people and organizations mixes the two with bad results. I see some devs coming from html+css with a little js background and then a need for devs with more experience of data structures, state management, async code, good architecture etc. Some devs has this but comies from the backend and might instead lack experience in js and js frameworks/ecosystems. I think more organizations need to look where they are, which devs they have and how they can help getting everybody getting better at advanced frontend programming.
'Needs' in this case might be where the money is. Most of the time it does not need to.
'complex interactions/workflows' usually comes down to CRUD in which case 'needs' is not true.
Starting towards the end. The comments about JS Framwork cadence doesn't nearly apply today as much as a few years ago. I mean Backbone was released in 2010 (8 years ago) and was probably the first JS SPA "framework" to gain significant traction. There have been many since then. Angular and Ember were also in 2010. React was first released in 2013 (over 5 years ago) and Vue was 2014.
Those have been the heavy hitters imho. All of which are pretty mature at this point. There are many others, of course, but that's been true of even desktop platforms. Yeah, Angular 2 was a big shift, but React, Vue and Angular are really the main players in this space. Most others take some queues from those three. Given that, it's a poor argument, and the language is more dated than the frameworks in question at this point.
Personally, I find SPAs are great for Line of business apps that need more complexity than a typical CRUD app can offer. Also, front end development IS DEVELOPMENT. Many snobby backend developers turn up their noses and feel it doesn't deserve the same level of consideration as backend development. They don't follow the same practices, consider use or lean on application designs already established in a number of toolkits.
Personally, I currently lean on React + material-ui. For the most part it has me covered, and I can find third party controls that at least match the styling. Read the Material Design guidelines. It isn't that hard and just try to follow the rules. Think about other applications you've used and push back on all features, punting as much as you can for as long as you can.
Avoid complexity at all costs. Break stuff apart into smaller pieces, and write code that's easy to replace.
Everything said and done, I think I'm just cranky at these types of articles that just indicate to me a point of view of someone unwilling to learn new things, or try new tools. I keep an eye on so much, and have for over two decades in dealing with web-based applications. I'm surprised how much the attitudes of some haven't changed in two decades.
They are still "web". Try working with C++ hard-heads. Everything from Jenkins, cloud services, application release over the web, to SPA visualising 3D point cloud is a "stupid HTML website". All they want to know is WHY IS IT TAKING SO LONG?! At least that was the case in one of my workplaces.
Kind of how I feel waiting for C++ to compile
Technology is also becoming increasingly layered and interdependent on brittle infrastructure. Abandoned projects can be a huge time waster as well, especially when they break. For example I’ve been working on trying to fix an abandoned web application written in an odd combination of languages and frameworks with a testing suite filled with old libraries and test scenarios that no longer make sense.. This thing is not broken, it’s shattered. It’s taken our team two entire sprints to get it somewhat working again. That’s the reality of modern software engineering.
(Here's a \s because I can imagine somebody saying the above.)
- Processing power of client devices will only grow, compute will cheapen but communication costs (speed of light/fiber/etc) are cheapening at a much slower rate.
- Repeatedly sending layout is wasteful, given site architectures that render the same page repeatedly
- Separation of UI and data is generally a good idea
- Sufficiently advanced SPAs offer Server Side Rendering (SSR), which makes them almost equivalent and yet more reusable than the alternatives (Java's JSP stuff, ASP.NET's ASPX mess, Ruby's ERB + layouts + partials stuff, Django's Jinja + layouts + partials stuff)
Mark my words, when wasm is widely accepted and lots of languages start compiling to it, people are going to start porting the SSR alternatives (JSP, ASPX, etc) to run on the frontend to achieve this same exact goal. I can't wait to see someone post on HN about "JSP in the browser".
There are of course a few things to keep track of, If sophistication in quantum communications grows faster than everyone expects, the landscape changes drastically. As a complete layman it seems possible to me to imagine arrays of entangled atoms being used at ISPs (possibly forced to be closer together) to reduce RTT to effectively near zero which fallback to regular over-the-wire communication for error correction or whatever else.
Almost 100% of the problems I've seen expressed with SPAs is from tooling or developers doing it wrong. Maybe that's it's biggest weakness, along with being an approach prone to accidental complexity.
Must full page reloads be eliminated?
(That's the real defining characteristics of SPAs)
For 95% of businesses a PWA with occasional full page reloads will be fine.
But for 5% of (mostly large) businesses, a kick ass SPA will be necessary.
Not having a client-side router strips out so much spa complexity.
maybe for apps where you really need persistent state i will use a router/full-spa, but a lot of apps don't need full persistent state across all page navigations.
The server will now have to have state or reload state on every request and that state could include many things that are not obvious like
- what page are you on
- which links should be shown in the menu
- are there other things on the page that needs to be shown that has little to do with the current request-path
Every front end page is likely to have a separate number of REST endpoints, so the code is effectively duplicated.
In my experience keeping as much of the code on the back end eliminates a lot of complexity, though I am far more competent with backend technologies, but I have yet to see a SPA app that reduced complexity.
Our SPAs are thouroughly tested (TDD, near 100% coverage). We make them mobile-first offline-first so they can be embedded in a phone app as well.
For CRUD, things that need to be searchable and things that need to work withoutJS, we usually have a rails/node app that renders views the classic way: server-side.
For static websites, we try to use static page generators like jekyll
A vast number of websites suffer from these problems. Therefore - your definition of "inexperienced" must apply to ~70% of web developers.
Maybe when the problem is this extensive it's time to stop blaming individuals and look for systemic problems.
"Native app over JSON markup"
Pros: cheap & fast (?)
Cons: obviously the logical structure of your app must (somehow) follow the structure of nested iframes in the page.
Thing about it. Should things really get more complex just because we are moving more of the computation to the client rather than having it sit at the server? Done right it remains the same.
But that can probably be said for any programming environment.
Still, building SPAs where a reloading site would suffice feels bad, and upgrading to CLJS is like adding a filter to a cigarette. Still not good for you or your surroundings.
Another problem is that we still haven't figured out the best way to write JS SPA applications. Even the React team is improvising as they go along. If you need any more proof just look at the new hooks api.
plus some good points
p.s. I thought vue came before react, but it's the other way around. Interesting
Seriously, if you're committing mistakes 1, 3, and 4, then your multi-page website is going to be awful, too. "SPA or not SPA" is far down the list of questions you need to be asking yourself.
Want to change your backend from C# to go? Easy. Want to change from angular to vue? Easy.
But programming is hard, and doing things for the long game is harder, and finding people with the skill and experience to pull it off is harder still.
Or... you could put all your biz logic in stored procedures and wrap it all with a nice .net Razer frontend, throw in a bunch of third party controls and call it a day.