Snowpack: Build a web application without a bundler(snowpack.dev)
snowpack.dev
Snowpack: Build a web application without a bundler
https://www.snowpack.dev/
237 comments
Exactly. There's very good reasons why tools like Webpack and Babel exist.
Here's two excellent articles that go over the history and use cases behind the JS tooling ecosystem:
http://tinselcity.net/whys/packers
https://www.swyx.io/writing/jobs-of-js-build-tools
As a counter-point, there's also valid reasons why a lot of the JS tooling ecosystem is painful to work with:
https://increment.com/development/the-melting-pot-of-javascr...
https://www.swyx.io/writing/js-tooling/
For myself personally, I'm quite happy with the React ecosystem. For the kinds of "desktop-app-in-a-browser" apps I work on, it's fantastic.
(Caveat: I'm a Redux maintainer, so I'm also a bit biased here.)
Here's two excellent articles that go over the history and use cases behind the JS tooling ecosystem:
http://tinselcity.net/whys/packers
https://www.swyx.io/writing/jobs-of-js-build-tools
As a counter-point, there's also valid reasons why a lot of the JS tooling ecosystem is painful to work with:
https://increment.com/development/the-melting-pot-of-javascr...
https://www.swyx.io/writing/js-tooling/
For myself personally, I'm quite happy with the React ecosystem. For the kinds of "desktop-app-in-a-browser" apps I work on, it's fantastic.
(Caveat: I'm a Redux maintainer, so I'm also a bit biased here.)
Plus theres a ton of starter kits for newbies on Github to get rolling without having to figure out the details. They are like mini-frameworks. Plenty for react, vue, etc, every combination.
The problem is--in my experience anyway--that too many people equate complexity with quality. That exists as part of human nature, it seems, and so naturally that has followed into the JavaScript ecosystem.
I've written and maintained several jQuery applications and if I'm being honest, I much prefer it over all the tooling we have today. jQuery isn't perfect because nothing is of course, but with a little discipline I never really had any trouble maintaining a jQuery application. In my opinion, all the tooling we have today does is obfuscates me away from my code and actually makes it harder to maintain.
I've written and maintained several jQuery applications and if I'm being honest, I much prefer it over all the tooling we have today. jQuery isn't perfect because nothing is of course, but with a little discipline I never really had any trouble maintaining a jQuery application. In my opinion, all the tooling we have today does is obfuscates me away from my code and actually makes it harder to maintain.
> The problem is--in my experience anyway--that too many people equate complexity with quality.
I find that a strange attitude. Complex systems are by definition harder to reason about, and therefore guaranteed to contain more bugs given the same amount of mental effort.
Sometimes complexity is unavoidable, but in general I find myself attracted to simpler systems, and consider that a sign of good engineering rather than the other way around.
I find that a strange attitude. Complex systems are by definition harder to reason about, and therefore guaranteed to contain more bugs given the same amount of mental effort.
Sometimes complexity is unavoidable, but in general I find myself attracted to simpler systems, and consider that a sign of good engineering rather than the other way around.
I agree with you, but you and I do not represent a majority.
I disagree. I spend most of my time at work in an Angular app and it sucks. The compile times suck, the developer experience sucks and it's not getting better, it's only getting worse. I had a chance to do some side work and decided against building a SPA. I wound up using ASP.NET Core Razor Pages (templated pages) and it's been a breath of fresh air - I haven't enjoyed myself this much writing web software in ages because I can get stuff done in very short order. If I need some more complex interactivity then I might sprinkle in something lightweight but I expect that to be the exception not the rule.
Death to complexity on the frontend for complexity's sake.
Death to complexity on the frontend for complexity's sake.
Re "complexity", for reference: the dependency tree (as in yarn list) of production-only installation of a default angularJS app created with ng new --minimal app is...
(I wanted to paste it, but it's too long = 2500 lines)
(I wanted to paste it, but it's too long = 2500 lines)
I think this is a separate problem. The JS ecosystem's love of dependencies is not about complexity, but about "not re-inventing the wheel" - everyone has been trained that for any problem there is a library to solve it, and writing code to solve the problem yourself is a waste of time.
This attitude is already hurting everyone, and it's only going to get worse. But it's a different thing than the complexity problem.
This attitude is already hurting everyone, and it's only going to get worse. But it's a different thing than the complexity problem.
For me it's the definition of complexity. Something that has many parts is complex.
If I want to dig into "how my angular app works", I can't, because I cannot browse 2500 npm packages on github to find out what they are doing. Even answering the question "does my app actually require this dependency" is completely impractical.
If I want to dig into "how my angular app works", I can't, because I cannot browse 2500 npm packages on github to find out what they are doing. Even answering the question "does my app actually require this dependency" is completely impractical.
To be fair, I had this problem learning Rails too. I like knowing how and why something works, and so the "it just does this because that's the convention for Rails" was confusing and annoying rather than helpful, and trying to dig into the Rails code base to work out why was pointless.
Part of the reason I love Go is because there's no magic. I can look at the definition of a std lib function and it's right there, in plain code, and makes sense.
But despite Go being simpler than Rails (for this reason), I'm not sure that any given Go project is simpler than any given Rails project. The moving parts are more obscure, definitely, but I'm not sure there are more of them or that they're providing more complexity.
Part of the reason I love Go is because there's no magic. I can look at the definition of a std lib function and it's right there, in plain code, and makes sense.
But despite Go being simpler than Rails (for this reason), I'm not sure that any given Go project is simpler than any given Rails project. The moving parts are more obscure, definitely, but I'm not sure there are more of them or that they're providing more complexity.
That's because Angular invented new problems to then valiantly tackle them. I've written a bit about this here: https://news.ycombinator.com/item?id=20040877
> I spend most of my time at work in an Angular app and it sucks. The compile times suck, the developer experience sucks and it's not getting better, it's only getting worse.
> I wound up using ASP.NET Core Razor Pages (templated pages) and it's been a breath of fresh air - I haven't enjoyed myself this much writing web software in ages because I can get stuff done in very short order.
Okay, so I've never worked in Angular, so I can't really speak (maybe there are Angular killer features that justifies using Angular?), but... If it looks like it'll be simpler in ASP.NET pages, go for it!
Everybody likes lighter pages, if your app is simple * doesn't need to be a heavy Angular SPA, you shouldn't be using them.
> I wound up using ASP.NET Core Razor Pages (templated pages) and it's been a breath of fresh air - I haven't enjoyed myself this much writing web software in ages because I can get stuff done in very short order.
Okay, so I've never worked in Angular, so I can't really speak (maybe there are Angular killer features that justifies using Angular?), but... If it looks like it'll be simpler in ASP.NET pages, go for it!
Everybody likes lighter pages, if your app is simple * doesn't need to be a heavy Angular SPA, you shouldn't be using them.
Most apps are simple, no I’m not talking about Facebook. The problem is templated pages apps are not considered sexy, so we build SPAs so we can look good (and pad the resume,) to the detriment of productivity.
At my day job, the meme that won and now dominate is "the percieved performance of a SPA is greater than that of a non-SPA". My calls for making our backend more performant are ignored (and probably ridiculed, because of how out-of-the-loop I seem). React for the win!
I hardly belong anywhere, it sometimes seems.
I hardly belong anywhere, it sometimes seems.
Personal anecdote: Angular 1.x at the time was a breath of fresh air because it allowed to create very clean, very modular front-ends with a lot of (unit) testing opportunities. The next best thing we had at the time (again, in my own experience) was Backbone, which was a lightweight layer on top of jquery but we didn't have any tests on that one.
So for us Java developers it was great. I don't know about Angular 2 and beyond, but I'm sure it has its place.
So for us Java developers it was great. I don't know about Angular 2 and beyond, but I'm sure it has its place.
I get the impression that OP's day job requires that they use Angular but they were able to use ASP.NET Core Razor Pages for a side project. I could be wrong.
Either way, I can confirm to OP's findings with Angular. I worked on an Angular project not too long ago and every time I hit Command-S I had to wait 10 seconds before the page would refresh. Manually refreshing wasn't an option, of course, because it was busy compiling. I tried to explain to my client that those 10 seconds were quickly adding up considering what my billable rate was but they didn't seem to mind. It was from Google and that's all they needed to know.
Either way, I can confirm to OP's findings with Angular. I worked on an Angular project not too long ago and every time I hit Command-S I had to wait 10 seconds before the page would refresh. Manually refreshing wasn't an option, of course, because it was busy compiling. I tried to explain to my client that those 10 seconds were quickly adding up considering what my billable rate was but they didn't seem to mind. It was from Google and that's all they needed to know.
React native’s fast refresh is... I’m not even sure of the words to describe it. Revelatory? I had no idea it was possible to develop apps so quickly and seamlessly while maintaining state as you code. I thought edit and continue debugging was the holy grail in C# until I used fast refresh and redux. I would not be exaggerating by saying that I would choose react native as a technology strictly because of how much fast refresh speeds up development of GUIs (but it’s great for many other reasons too). I can’t wait for fast refresh to make its way into react web. We have several large, complex apps in ionic/Cordova/angular stack and now that ionic react is stable it won’t be long for us to jump off Angular altogether.
We have a large desktop application that hosts tabs of other react applications and provides windowing features, all built in Electron, that is written in React. we can edit a component within an app and save it and have the UI update with the same state and the new component change in under a second. react native fast refresh is even better because it’s understanding of life cycles and hooks is better but hot reloading within a react app is extremely performant for us. I wonder why you’re having to wait so long?
We have a large desktop application that hosts tabs of other react applications and provides windowing features, all built in Electron, that is written in React. we can edit a component within an app and save it and have the UI update with the same state and the new component change in under a second. react native fast refresh is even better because it’s understanding of life cycles and hooks is better but hot reloading within a react app is extremely performant for us. I wonder why you’re having to wait so long?
I've started playing around with React Native lately and so far have been pleasantly surprised. I have also used NativeScript quite a bit and it too has a very fast compile and refresh. I don't know what it is about Angular that makes the refresh so slow.
Same here, I made it sure that our next project isn't going to be an SPA. It is absolutely madness what is going on in the frontend development space.
[deleted]
These sound like implementation issues. Why does compile time suck? Do you cache compiled files and update only what has changed? Are you doing minimization and / or compressing in development? If compile time isn't under a second during development, you're doing it wrong.
It does not suck. The compile times are OK and are getting better. Angular (and other) SPAs have capabilities no RoR, ASP.NET or Django setup can even begin to touch. Separating the back-end from the front-end with an independent API is also a god-send.
Death to remaining in the dark ages for nostalgia's sake.
Death to remaining in the dark ages for nostalgia's sake.
Oh, it does suck, hugely. Longer time to first paint, more bandwidth, more cpu and battery usage, huge dependency chains, slow "live" updates...
A lot of my issue with the Javascript-heavy present of "modern" SPA websites is that they have to recreate native browser functionality, which is inevitably slower and worse.
Way too many websites could have the same functionality, in a simpler form, with better performance with a more "traditional" stack. You can even have your API separated front-end and back-end via server-side rendering (by which I mean old-style server-side rendering).
The modern zeitgeist is mostly hype, fad, and novelty.
A lot of my issue with the Javascript-heavy present of "modern" SPA websites is that they have to recreate native browser functionality, which is inevitably slower and worse.
Way too many websites could have the same functionality, in a simpler form, with better performance with a more "traditional" stack. You can even have your API separated front-end and back-end via server-side rendering (by which I mean old-style server-side rendering).
The modern zeitgeist is mostly hype, fad, and novelty.
> The compile times are OK and are getting better.
Our frontend Angular test runs take 25 minutes to run less than 2,000 unit (not integration) tests. That's just nonsense. I don't blame Angular so much as I blame the JS ecosystem. For comparison our backend unit test runs (ASP.NET Core) take 3 minutes to run 6,000 tests.
You can argue we're doing something wrong, but as a company with a a thousand or so devs - reaching out to the most experienced frontend devs we have, their answer is: you've got too many tests, split up your SPA into smaller SPAs. Great, more complexity and dependency management hell.
Our frontend Angular test runs take 25 minutes to run less than 2,000 unit (not integration) tests. That's just nonsense. I don't blame Angular so much as I blame the JS ecosystem. For comparison our backend unit test runs (ASP.NET Core) take 3 minutes to run 6,000 tests.
You can argue we're doing something wrong, but as a company with a a thousand or so devs - reaching out to the most experienced frontend devs we have, their answer is: you've got too many tests, split up your SPA into smaller SPAs. Great, more complexity and dependency management hell.
I would write backend code in almost any framework before writing Angular, Ember, React... Backend is 100% a better experience.
I can't wait for Rust/WASM to eat Javascript alive. I'm considering writing my next frontend project in Rust.
I can't wait for Rust/WASM to eat Javascript alive. I'm considering writing my next frontend project in Rust.
I think you're right in that all this complexity didn't come out of a vacuum but I also feel the complexity in front end web development and the development costs that come from it are a real issue and shouldn't be dismissed. Yes I've worked in jQuery spaghetti and experienced that, but just because it might have been worse doesn't mean the situation in front end web development is good or can't be improved.
Anyone who's had to maintain one of these projects long term without a massive team or inherited an older codebase understands that there are serious churn / depenency hell / code rot and complexity issues here and layering more and more abstractions on top to try and dig ourselves out of the hole we're in might not be working anymore.
anecdotally I got out of JS / frontend mid last year after many many years in it and felt at the time that I was burnt out and had lost my passion for development. Maybe it was just too long for me in one area.
Anyone who's had to maintain one of these projects long term without a massive team or inherited an older codebase understands that there are serious churn / depenency hell / code rot and complexity issues here and layering more and more abstractions on top to try and dig ourselves out of the hole we're in might not be working anymore.
anecdotally I got out of JS / frontend mid last year after many many years in it and felt at the time that I was burnt out and had lost my passion for development. Maybe it was just too long for me in one area.
> the complexity in front end web development and the development costs that come from it are a real issue and shouldn't be dismissed
I would argue that it's an absurdly overblown issue. The "costs" are a clear net gain which is why these tools are all but ubiquitous. Developer hype only goes so far, these tools are a proven success across every major tech company with a front-end presence. All this supposed complexity is a holistic improvement over the past, especially because all the same libraries and techniques from 20 years ago and everything in between work exactly the same way today.
> Anyone who's had to maintain one of these projects long term without a massive team or inherited an older codebase understands that there are serious churn / depenency hell / code rot and complexity issues here and layering more and more abstractions on top to try and dig ourselves out of the hole we're in might not be working anymore.
Sounds like literally every piece of corporate software I've worked on that's older than 10 years. 10 year old php app? 15 year old c++ app? 15 year old vb6 app? 15 year old c app? Those are all examples of previous nightmares I have experienced and none of them were any easier to handle than a shitty angular mess. At least the browser is incredibly resilient with regard to failure states... try debugging intermittent crashes in a legacy c++ app preserved in a tacky lacquer of clever templating voodoo; nothing in js land even comes close to my time in the c++ insane asylum.
I would argue that it's an absurdly overblown issue. The "costs" are a clear net gain which is why these tools are all but ubiquitous. Developer hype only goes so far, these tools are a proven success across every major tech company with a front-end presence. All this supposed complexity is a holistic improvement over the past, especially because all the same libraries and techniques from 20 years ago and everything in between work exactly the same way today.
> Anyone who's had to maintain one of these projects long term without a massive team or inherited an older codebase understands that there are serious churn / depenency hell / code rot and complexity issues here and layering more and more abstractions on top to try and dig ourselves out of the hole we're in might not be working anymore.
Sounds like literally every piece of corporate software I've worked on that's older than 10 years. 10 year old php app? 15 year old c++ app? 15 year old vb6 app? 15 year old c app? Those are all examples of previous nightmares I have experienced and none of them were any easier to handle than a shitty angular mess. At least the browser is incredibly resilient with regard to failure states... try debugging intermittent crashes in a legacy c++ app preserved in a tacky lacquer of clever templating voodoo; nothing in js land even comes close to my time in the c++ insane asylum.
What do you do now?
Tools don't have to be complex. We have about a fifteen line json config for brunch for the usual build chain. It took a day or two to develop and can be copied with few changes to other projects. Compare this to one of our devs spending over a week and hundreds of lines of config with webpack and still couldn't achieve an identical config. The de facto tools like webpack, gulp, grunt, etc. are unnecessary complexity monsters. That's what people are complaining about here and they have a right to. It's not the idea that's flawed, it's the ridiculously over complex, constantly breaking implementations like the ones above and most similar tools. Not too mention the low quality of such tools and npm itself requiring one to now be an expert on not only the build chain, but npm and yarn before even starting any project. The complaints are more than valid when there are tools that do the same job without the unnecessary complexity.
> Compare this to one of our devs spending over a week and hundreds of lines of config with webpack and still couldn't achieve an identical config. The de facto tools like webpack, gulp, grunt, etc. are unnecessary complexity monsters.
> That's what people are complaining about here and they have a right to. It's not the idea that's flawed, it's the ridiculously over complex, constantly breaking implementations like the ones above and most similar tools.
Well, the complexity is because webpack/gulp/grunt are do-everything tools. There are lots of features to assist everyone, and usually if you have some obscure requirements, webpack has an solution.
Yeah, webpack is complex - IMO one shouldn't use webpack just to bundle up JS files. There are opinionated tools like Parcel or CRA(which automatically configures webpack under-the-hood), and those will fit 90% of the users. Only the left 10% which existing opinionated solutions cannot accommodate can fiddle with the webpack config directly.
> Not too mention the low quality of such tools and npm itself requiring one to now be an expert on not only the build chain, but npm and yarn before even starting any project.
Well, do you really think JS has low-quality tools? I really don't see them as low-quality... And you should know npm/yarn before starting a JS project; it's like knowing gcc/clang before starting a C project, or knowing cargo before starting a Rust project.
> The complaints are more than valid when there are tools that do the same job without the unnecessary complexity.
(Assuming you're talking about npm/yarn) If you can do the same job without all the dependencies, you don't have to know package managers. If you want to, you should know the package managers.
> That's what people are complaining about here and they have a right to. It's not the idea that's flawed, it's the ridiculously over complex, constantly breaking implementations like the ones above and most similar tools.
Well, the complexity is because webpack/gulp/grunt are do-everything tools. There are lots of features to assist everyone, and usually if you have some obscure requirements, webpack has an solution.
Yeah, webpack is complex - IMO one shouldn't use webpack just to bundle up JS files. There are opinionated tools like Parcel or CRA(which automatically configures webpack under-the-hood), and those will fit 90% of the users. Only the left 10% which existing opinionated solutions cannot accommodate can fiddle with the webpack config directly.
> Not too mention the low quality of such tools and npm itself requiring one to now be an expert on not only the build chain, but npm and yarn before even starting any project.
Well, do you really think JS has low-quality tools? I really don't see them as low-quality... And you should know npm/yarn before starting a JS project; it's like knowing gcc/clang before starting a C project, or knowing cargo before starting a Rust project.
> The complaints are more than valid when there are tools that do the same job without the unnecessary complexity.
(Assuming you're talking about npm/yarn) If you can do the same job without all the dependencies, you don't have to know package managers. If you want to, you should know the package managers.
What I mean when I say by 'know npm/yarn' is that you have to know the internals, how they operate, and why they break. You have to debug npm/yarn themselves. That's not something one should know to build anything on the frontend. In many years with other languages' dependency tools like PHP's composer and Clojure's leiningen, I've had to deal with dependency and internal package manager issues maybe once or twice and that's being generous as I really don't remember any times. So do I think the JS tools are shitty? They are shitty beyond all fucking imagination and comparing them to tools in other languages can objectively prove that by simply looking at the number of times and the way these tools break vs. the tools that don't break. I wouldn't be so adamant about it except I spend more time (as I'm sure many here do) dealing with breakages in npm and yarn than in any other system related deployment task. And the insanity of it is that this isn't even application code. It just concats some files and runs them through a few code processors like babel and scss. That's fucking insanely bad tooling.
As far as webpack, I understand that it's a jack of all trades. But if even trying to replicate a simple bundling config takes many days, then it's a perfect example of a tool that's not only overly complex, but one that doesn't do its own core job well.
As far as webpack, I understand that it's a jack of all trades. But if even trying to replicate a simple bundling config takes many days, then it's a perfect example of a tool that's not only overly complex, but one that doesn't do its own core job well.
The tooling in JavaScript is fantastic. I don’t love much about JS, but I do Python now and boy are dependencies and packaging worse.
For the vast majority of web users the only sites they ever visit that really need any of these front end frameworks are their webmail and social network platforms of choice. For everywhere else a combination of backend processing with a smattering of vanilla javascript, or jquery, would provide a far superior user experience.
... a far superior user experience.
It's incrediy subjective obviously, but in my 25 years of web dev (full stack) rendering speed has been the number one gripe from users. I've spent thousands of hours optimizing web things. The biggest impact on user perception of speed was the move to Web 2.0 eg JS apps that fetch data with 'ajax' and update the DOM.
If my experience is anything to go by users absolutely prefer client side rendered apps (with SSR, hydration, caching, memoization, optimal data structuring, etc, etc).
No doubt a huge amount of client side JS is garbage, and users would be better served by a server rendered website than a bad client side rendered app, but they'd be even better off still with a good client side rendered site.
It's incrediy subjective obviously, but in my 25 years of web dev (full stack) rendering speed has been the number one gripe from users. I've spent thousands of hours optimizing web things. The biggest impact on user perception of speed was the move to Web 2.0 eg JS apps that fetch data with 'ajax' and update the DOM.
If my experience is anything to go by users absolutely prefer client side rendered apps (with SSR, hydration, caching, memoization, optimal data structuring, etc, etc).
No doubt a huge amount of client side JS is garbage, and users would be better served by a server rendered website than a bad client side rendered app, but they'd be even better off still with a good client side rendered site.
I often use a mix, with ASP.NET Core MVC doing most of the work, but using Javascript to load some things at the client-side - for example, table data.
This provides fast page loads, with the ability to load additional data without reloading the whole page.
This provides fast page loads, with the ability to load additional data without reloading the whole page.
I don't see what's wrong with this post that it should be downvoted like it has been. I personally agree with this sentiment. It's like the developers who immediately rush to massive scale when all they've been asked to build is effectively a prototype. I've seen it time and again... they get bogged down in making sure the app can scale when they have yet to have a single paying customer for the product. At that point, they don't even know if there is even a market for the product and they're trying to build something that millions of users can use right out of the box. The priorities are off.
If a combination of back-end processing with some vanilla javascript, or jquery will get you to market for your first 100-1000 users (which, we know it will because that used to be the only way we could do things, on much less powerful hardware no less) then I say go with that. In the mean time you can work with the stakeholders to put together a strategy for scaling up as demand increases.
If a combination of back-end processing with some vanilla javascript, or jquery will get you to market for your first 100-1000 users (which, we know it will because that used to be the only way we could do things, on much less powerful hardware no less) then I say go with that. In the mean time you can work with the stakeholders to put together a strategy for scaling up as demand increases.
I replied to one of your other posts about how great I think React development is, but I want to also state my wholehearted agreement with this thread. For things you would use a SPA framework for, it’s really the types of thing that are apps that happen to be hosted through a web browser. They’re very distinct from web pages. Most user facing websites should be built with backend server processing and js/query. React is nice because you can progressively enhance particular components, so it works well as a complement to a backend language, but in that case the tooling overhead is pretty high for what you get. So in those cases I typically go the jQuery route as well.
> It's like the developers who immediately rush to massive scale when all they've been asked to build is effectively a prototype.
I just finished working in the public sector and it's absolutely terrible for this. We had a microservice based event-driven architecture, all on AWS, load balancers everywhere. It was so complicated not a single person knew the entire architecture.
Current number of users: 65
Expected maximum number of users ever: 8000
I just finished working in the public sector and it's absolutely terrible for this. We had a microservice based event-driven architecture, all on AWS, load balancers everywhere. It was so complicated not a single person knew the entire architecture.
Current number of users: 65
Expected maximum number of users ever: 8000
I'd love to see how Google Sheets would be implemented with a smattering of vanilla JavaScript
I don't think Google Sheets falls into the category what most web sites need to work.
It's about using the right tool for the right job.
Not only that. But even if you are making a very simple static HTML website, you start bumping into problems very quickly. Here are a few things where Gulp/Webpack have helped.
- Auto-browser reloading.
- Minification and compiling all JS/CSS into single files.
- Partials for Header/Footer/Menus.
- CSS/JS files versioning (the browser-caching issue).
Sure you can build a static website without all these niceties. But these are a one time investment (gulp+webpack) that you can re-use for your future websites and work.
- Auto-browser reloading.
- Minification and compiling all JS/CSS into single files.
- Partials for Header/Footer/Menus.
- CSS/JS files versioning (the browser-caching issue).
Sure you can build a static website without all these niceties. But these are a one time investment (gulp+webpack) that you can re-use for your future websites and work.
> These tools aren't the simplest things, but so is everything, everywhere.
No. An insanely complex Eclipse based Java product I maintained had hundreds of dependencies (including transitive), from a handful of vendors (> 20). Apparently, an simple JS app[0] can have 40000 packages (from hundreds of vendors).
This is insane.
[0] https://stackoverflow.com/questions/55416657/why-do-i-have-4...
No. An insanely complex Eclipse based Java product I maintained had hundreds of dependencies (including transitive), from a handful of vendors (> 20). Apparently, an simple JS app[0] can have 40000 packages (from hundreds of vendors).
This is insane.
[0] https://stackoverflow.com/questions/55416657/why-do-i-have-4...
> Do people think we shouldn't use compilers because we 'can' write binary ELF files directly? Same goes to JS.
The problem however is that JS is a perfectly fine programming language by now. Think about it, why are we still stuck with Webpack et al? It's because of inconsistent or missing support for modules / imports, or because of a risk that a JS feature you use does not work on a certain browser. And there's JSX of course.
JS is not assembly.
The problem however is that JS is a perfectly fine programming language by now. Think about it, why are we still stuck with Webpack et al? It's because of inconsistent or missing support for modules / imports, or because of a risk that a JS feature you use does not work on a certain browser. And there's JSX of course.
JS is not assembly.
I think part of the thing that people complain as complexity is the fact that there is too much choice in the web world and no one framework/tool/language is dominant and clearly better than the rest.
> Most of JS tooling stems from 1. different browsers
Do people struggle a lot with cross-browser issues these days? It isn't like it was back in the day, when basic stuff like the box model worked wildly differently in IE. And almost everyone's on a rolling-release, auto-updated browser, so you don't have to worry about testing on old versions; even big websites like Stack Overflow only support the last couple releases of the most popular browsers: https://meta.stackexchange.com/questions/56161/which-browser...
I still test on multiple browsers, and every once in a while I'll need to fix a bug that only shows up in one browser. But JavaScript frameworks and build tooling don't really help with that, do they? (Am I missing out?)
Do people struggle a lot with cross-browser issues these days? It isn't like it was back in the day, when basic stuff like the box model worked wildly differently in IE. And almost everyone's on a rolling-release, auto-updated browser, so you don't have to worry about testing on old versions; even big websites like Stack Overflow only support the last couple releases of the most popular browsers: https://meta.stackexchange.com/questions/56161/which-browser...
I still test on multiple browsers, and every once in a while I'll need to fix a bug that only shows up in one browser. But JavaScript frameworks and build tooling don't really help with that, do they? (Am I missing out?)
Yes. If you're a front-end developer at some capacity, developing anything of use for > 0 users, you'll have hell of a lot of browser compatibility issues.
People will browse your app from ancient mobile phones. Weird smart TVs. play consoles. Chinese browsers you've never heard of but come bundled with some we-something, they will browse your app from PoS, from a DJI smart RC, from a fridge. And from IE6.
And you know what's the best way to mitigate all that mental load? You just start upfront with a framework that was already battle-tested on all these weird browsers.
People will browse your app from ancient mobile phones. Weird smart TVs. play consoles. Chinese browsers you've never heard of but come bundled with some we-something, they will browse your app from PoS, from a DJI smart RC, from a fridge. And from IE6.
And you know what's the best way to mitigate all that mental load? You just start upfront with a framework that was already battle-tested on all these weird browsers.
What framework do you recommend for wide browser support? React certainly doesn't claim to support anything like feature-phones or IE 6; the lowest they go is IE 9, and that's only if you load additional polyfills: https://reactjs.org/docs/react-dom.html#browser-support
Oh you'd be surprised.
Safari never fails to make you question why, and Firefox and Chrome still have enough differences to catch you off-guard from time to time.
Safari never fails to make you question why, and Firefox and Chrome still have enough differences to catch you off-guard from time to time.
A lot of features are still wildly different between browsers. SVG being one particular pain point for me. And Safari is the browser that I have the most issues with recently.
It's not about struggling so much as about avoiding a situation where one small problem makes a site either look visually 'broken' or (worse) fail to function correctly.
There are way too many small bugs and incompatibilities like these, and way, way too many browser versions still seeing use by at least a small percentage of users, to worry about them individually, unless you want that to eat up all your time.
So your choice is between "be okay with a broken experience for some users", or "use build tools to compile to a common-ancestor target of near-universally-supported CSS and JS".
There are way too many small bugs and incompatibilities like these, and way, way too many browser versions still seeing use by at least a small percentage of users, to worry about them individually, unless you want that to eat up all your time.
So your choice is between "be okay with a broken experience for some users", or "use build tools to compile to a common-ancestor target of near-universally-supported CSS and JS".
What build tools do you use that ensure your site works consistently across different browser versions without needing any browser-version-specific testing/fixes on your part?
I've worked on web pages that use what seems to be a pretty standard Webpack/Babel/PostCSS/etc setup, and they still ran into some issues where layout or behavior was different between browsers. Either because they used a CSS property value or JavaScript API (or API parameter/option) that wasn't available everywhere, or because of more subtle disagreements between browsers about things like where an inline element's containing block is.
I've worked on web pages that use what seems to be a pretty standard Webpack/Babel/PostCSS/etc setup, and they still ran into some issues where layout or behavior was different between browsers. Either because they used a CSS property value or JavaScript API (or API parameter/option) that wasn't available everywhere, or because of more subtle disagreements between browsers about things like where an inline element's containing block is.
You're right, it's not possible to eliminate the need for testing/fixes. I didn't say it was. It's a tradeoff; compiling to a stable older set of features reduces bugs but doesn't eliminate them.
Part of the work has to be on the developer. There are certain properties that will screw up positioning when used with flex elements in IE, for example, and knowing what those are and how to avoid those combinations is part of the cost of skillfully using flexbox. The compiler can't always do the work, but we should let it do as much as it can.
Part of the work has to be on the developer. There are certain properties that will screw up positioning when used with flex elements in IE, for example, and knowing what those are and how to avoid those combinations is part of the cost of skillfully using flexbox. The compiler can't always do the work, but we should let it do as much as it can.
No idea why you're getting downvoted. I'm wondering the same thing. I've even stopped prefixing anything and haven't seen any issues in any browser.
two points
1. the most of JS tooling stemming from browser compatibility issues does not mean that the issues still need to exist at the point that the tooling was established - it can take a while for established stuff to be moved out.
2. I think for most sites it isn't a problem, but for me the last 3 years has been work on big SPAs that need to generally also handle IE9 (degrade gracefully). And there is always stuff going on.
1. the most of JS tooling stemming from browser compatibility issues does not mean that the issues still need to exist at the point that the tooling was established - it can take a while for established stuff to be moved out.
2. I think for most sites it isn't a problem, but for me the last 3 years has been work on big SPAs that need to generally also handle IE9 (degrade gracefully). And there is always stuff going on.
> Complexity needs to exist somewhere, and using an abstraction to hide them is something natural.
Yes but designing the right abstraction is an artform, and I suppose that these tools haven't yet found it.
Yes but designing the right abstraction is an artform, and I suppose that these tools haven't yet found it.
Browser incompatibilities are mostly gone, where they still exist frameworks tend to do nothing to solve them. I write web stuff and I used to do the dance of testing with a bunch of browsers and fixing stuff. Since IE 11 there have been basically nothing to fix, the browsers really do behave the same.
> Browser incompatibilities are mostly gone
Not really, and not even something that pertains to "really old" browsers.
As a somewhat recent example, in order to implement "SameSite=None" properly, one has to ensure it's _not_ sent to browsers (including recent Safaris and Chromes) which implement it badly. See also: https://www.chromium.org/updates/same-site/incompatible-clie...
Not really, and not even something that pertains to "really old" browsers.
As a somewhat recent example, in order to implement "SameSite=None" properly, one has to ensure it's _not_ sent to browsers (including recent Safaris and Chromes) which implement it badly. See also: https://www.chromium.org/updates/same-site/incompatible-clie...
Agreed. I've concluded the reason there's so much disagreement about the "right" level of tooling/abstraction is because there's a such a wide variety of "web applications" and developers with varying amounts of experience building complex applications.
jQuery still can be used with webpack, but you'll be cursing webpack while configuring it to work like that. The thing about webpack is that it exposes too much complexity that setting it up is always painful. Not many people are against compilation itself.
[deleted]
I really enjoyed react when it first came out and there was little fussing with browserify (3-4 years ago).
But now this tooling is out of hand. I threw up my hands and found sanity again in simplicity (my username namesake).
Now I deploy apps with no more than 100 lines of JS.
Again, not prescriptive, just my own journey.
But now this tooling is out of hand. I threw up my hands and found sanity again in simplicity (my username namesake).
* Django
* jquery
* intercoolerjs (https://intercoolerjs.org)
* plain old docker
Now I deploy apps with no more than 100 lines of JS.
Again, not prescriptive, just my own journey.
I was once working on a small tool that I tried different iterations of using a small variety of approaches; I tried implementing it in bash, perl, python, ES6 JS (classes and more), and a few other methods (I think at one point I even tried a LibreOffice spreadsheet).
But I kept getting mired and "stuck" in how I should architect things, or what framework to use, or this or that. I eventually decided that I wanted it to be a browser-based app of some sort (thus the road of ES6) - but then I started to wonder what tooling to use there. Lots of questions, etc - and I never got that far with it.
I eventually wised up and realized that it didn't matter what I chose - what I needed was the application to work. Who cares about frameworks, requirejs, css frameworks, etc - I just wanted something working. So I stepped back...and decided to chuck all of that away.
I ended up with a basic webpage, with a script tag and the code inside that - nothing fancy, purely procedural, old-school javascript functions, tied to events. Bare bones, basic.
...and I made real progress for the first time.
Basically, by regressing to the relative simplicity of Javascript back from the 1990s, I was able to get my tool finally going, without having to worry about the last two decades of cruft around that language. Now, I could have also done it using Python or anything else, in the same manner - but again, I wanted it to be browser based.
As you note, my own journey, and not something I'd tell anyone else to do (and certainly not something meant for a production environment!) - but for myself, and my need, this fit the bill. I'm still working on it; I figure when I complete it proper-like, I can go back and refactor it to something more respectable. Or maybe not.
After all, if it works, why try to break it? In the end, I want the results from the tool - who cares what it looks like under the hood, so long as it works.
But I kept getting mired and "stuck" in how I should architect things, or what framework to use, or this or that. I eventually decided that I wanted it to be a browser-based app of some sort (thus the road of ES6) - but then I started to wonder what tooling to use there. Lots of questions, etc - and I never got that far with it.
I eventually wised up and realized that it didn't matter what I chose - what I needed was the application to work. Who cares about frameworks, requirejs, css frameworks, etc - I just wanted something working. So I stepped back...and decided to chuck all of that away.
I ended up with a basic webpage, with a script tag and the code inside that - nothing fancy, purely procedural, old-school javascript functions, tied to events. Bare bones, basic.
...and I made real progress for the first time.
Basically, by regressing to the relative simplicity of Javascript back from the 1990s, I was able to get my tool finally going, without having to worry about the last two decades of cruft around that language. Now, I could have also done it using Python or anything else, in the same manner - but again, I wanted it to be browser based.
As you note, my own journey, and not something I'd tell anyone else to do (and certainly not something meant for a production environment!) - but for myself, and my need, this fit the bill. I'm still working on it; I figure when I complete it proper-like, I can go back and refactor it to something more respectable. Or maybe not.
After all, if it works, why try to break it? In the end, I want the results from the tool - who cares what it looks like under the hood, so long as it works.
So good to find someone else who went back to the 90ies stack!
After playing around with some react/vue/express/angular/younameit apps for various clients I am more than happy to escape the dependency hell and write efficient code in pure JS that load basically instantly and doesn't need a build environment in the first place. The last straw for me was spending over a day trying to find the right versions for node and all the packages involved to at least get a "legacy app" I inherited running.
I find that I don't even need jQuery anymore, support for things like closest() or a simple document.querySelector is so good that I save those few kb as well.
After playing around with some react/vue/express/angular/younameit apps for various clients I am more than happy to escape the dependency hell and write efficient code in pure JS that load basically instantly and doesn't need a build environment in the first place. The last straw for me was spending over a day trying to find the right versions for node and all the packages involved to at least get a "legacy app" I inherited running.
I find that I don't even need jQuery anymore, support for things like closest() or a simple document.querySelector is so good that I save those few kb as well.
I'm doing this as well, mostly. It's surprisingly productive! I don't use jQuery or anything like that either. For DOM manipulation I've got a little utility module that I'll include in projects. I know what every function does and it's mostly just some convenience wrappers around standard APIs, I have maybe 15-20 functions in total and I don't think any one of them is longer than 20 lines (including comments and white space.)
I've written some reasonably complex apps this way, but I'd probably have a hard time selling this approach to fellow devs, most I've worked with are very entrenched in <insert favorite framework here> and not particularly keen on doing things differently. I can understand and appreciate that point of view, and will acquiesce to the will of the team, but in the past year or so I've had the luxury of being the sole dev on most of the projects I've worked on so this is what I've done and it's been wonderful.
F5 is my compiler, it requires no additional configuration beyond what's already in the HTML, and it's super fast. I love it! :o)
I've written some reasonably complex apps this way, but I'd probably have a hard time selling this approach to fellow devs, most I've worked with are very entrenched in <insert favorite framework here> and not particularly keen on doing things differently. I can understand and appreciate that point of view, and will acquiesce to the will of the team, but in the past year or so I've had the luxury of being the sole dev on most of the projects I've worked on so this is what I've done and it's been wonderful.
F5 is my compiler, it requires no additional configuration beyond what's already in the HTML, and it's super fast. I love it! :o)
I write react professionally, but for my freelance projects or any personal projects I came to a similar stack when it comes to simplicity.
Laravel NGINX VanillaJS/WebComponents (toying with Svelte right now) MariaDB
Fast prototyping, simple deployment, almost no time spent with tooling.
A recent example with too much tooling I had was with Root's bedrock+trellis+sage. They do make working with WordPress management for a developer (a lot less clicking that with normal WP setup). But the frontend setup, webpack, backend, browserify and all of that is so complicated and slow. I was able to set it up on one machine, but failed to git clone the same project on two others. Scripts would be missing, things wouldn't load etc. Nightmare.
Laravel NGINX VanillaJS/WebComponents (toying with Svelte right now) MariaDB
Fast prototyping, simple deployment, almost no time spent with tooling.
A recent example with too much tooling I had was with Root's bedrock+trellis+sage. They do make working with WordPress management for a developer (a lot less clicking that with normal WP setup). But the frontend setup, webpack, backend, browserify and all of that is so complicated and slow. I was able to set it up on one machine, but failed to git clone the same project on two others. Scripts would be missing, things wouldn't load etc. Nightmare.
If you're a fan of this type of libs, you should also check out https://stimulusjs.org/ and https://umbrellajs.com/.
This is my first time seeing any of these awesome libraries linked here, but for my money I just spent half an hour reading all the intercooler docs and it looks like a winner. I don’t see the benefit of Umbrella over jQuery when you take into account the browser support and libraries available for the latter, and it seems that intercooler is stimulus + turbo links but on steroids.
These both look cool. I've learned some Vue in the past but I strongly prefer these kinds of small, self contained libraries for my Flask + PicnicCSS + very simple JS apps.
I mentioned this library in a previous comment, but LiteDOM might be interesting to you as it is somewhat similar to Vue:
https://litedom.js.org/
https://litedom.js.org/
LiteDOM also seems very promising:
https://litedom.js.org/
https://litedom.js.org/
I wrote my own (minimal) library to do what intercooler does in an effort to strictly progressively enhance a UI for dynamic updates while embracing server-side templating and rendering (ASP.NET Core). I can’t believe I didn’t find this at the time! It’s much more thorough and capable than what I wrote, I’m definitely using this going forward, thank you!
That intercoolerjs looks pretty decent.
With regards to tooling I agree it is too complicated. I really wish that everyone would coalesce around a standard set of tools. But it would be the equivalent of cat herding.
With regards to tooling I agree it is too complicated. I really wish that everyone would coalesce around a standard set of tools. But it would be the equivalent of cat herding.
Huh? React tooling options have never been simpler. Literally one command and you're ready to go.
And it pulls hundreds of megabytes of shit behind the scenes with god knows what vulnerabilities & backdoors, the resulting browser bundle is hundreds of kilobytes of crap the browser has to download & parse (instant on a fast machine & internet, less so on a cheap Android device on crappy underground subway Wi-Fi), etc.
This complexity is out of hand. The worst is we now use yet more solutions (for example server-side rendering, which now needs its own Node server and it's yet another thing to deploy in addition to your main backend) just to try and dig ourselves out of the hole we dug in the first place. Imagine if we suddenly decided concrete isn't cool anymore and everyone should use duct tape. Given its obvious shortcomings we now waste time trying to make tape work, going as far as making concrete-reinforced duct tape and calling it the best new thing of the day... instead of just using the "uncool" concrete in the first place.
This guy has a point, for 90% of projects, you don't need React (those who tell you otherwise are trying to justify their career and position because from my experience most React/Vue front-end positions at companies are pointless and just add unneeded complexity).
War story time: a client was building a complex financial product (includes real-time automated trading, etc). The backend was finished but we couldn't test it because despit several months months the React front-end still wasn't ready and days were wasted on basic things like a signup form, displaying the 2FA QR code, user onboarding wizard, etc. Let that sink in for a minute: we could successfully decide when to make transactions worth millions of dollars automatically, but dug a hole so deep on the front-end that we couldn't do basic things that even the first iteration of HTML forms could do just fine 20 years ago. The powers that be didn't want to lose face so they still kept at using that trainwreck of a front-end instead of ripping the whole thing out and rebuilding it using HTML forms in a matter of hours. I didn't stick around to see if they ever finished the project.
This complexity is out of hand. The worst is we now use yet more solutions (for example server-side rendering, which now needs its own Node server and it's yet another thing to deploy in addition to your main backend) just to try and dig ourselves out of the hole we dug in the first place. Imagine if we suddenly decided concrete isn't cool anymore and everyone should use duct tape. Given its obvious shortcomings we now waste time trying to make tape work, going as far as making concrete-reinforced duct tape and calling it the best new thing of the day... instead of just using the "uncool" concrete in the first place.
This guy has a point, for 90% of projects, you don't need React (those who tell you otherwise are trying to justify their career and position because from my experience most React/Vue front-end positions at companies are pointless and just add unneeded complexity).
War story time: a client was building a complex financial product (includes real-time automated trading, etc). The backend was finished but we couldn't test it because despit several months months the React front-end still wasn't ready and days were wasted on basic things like a signup form, displaying the 2FA QR code, user onboarding wizard, etc. Let that sink in for a minute: we could successfully decide when to make transactions worth millions of dollars automatically, but dug a hole so deep on the front-end that we couldn't do basic things that even the first iteration of HTML forms could do just fine 20 years ago. The powers that be didn't want to lose face so they still kept at using that trainwreck of a front-end instead of ripping the whole thing out and rebuilding it using HTML forms in a matter of hours. I didn't stick around to see if they ever finished the project.
Just because a new solution is trending doesn't mean you have to figure out how to use it in your tech stack. Evaluate your needs and where it may or may not fit and decide accordingly.
> This complexity is out of hand. The worst is we now use yet more solutions (server-side rendering, which now needs its own Node server and it's yet another thing to deploy) just to try and dig ourselves out of the hole we dug in the first place.
No, someone had a project that required SSR and for reasons important to their project wanted to build out that functionality in node. You don't have to use it just because it's out there if you find you don't have compelling reasons to apply it to your project.
Just because it doesn't fit your project doesn't mean it's useless for everyone else. Your 90% of projects aren't other people's 90% of projects.
> This complexity is out of hand. The worst is we now use yet more solutions (server-side rendering, which now needs its own Node server and it's yet another thing to deploy) just to try and dig ourselves out of the hole we dug in the first place.
No, someone had a project that required SSR and for reasons important to their project wanted to build out that functionality in node. You don't have to use it just because it's out there if you find you don't have compelling reasons to apply it to your project.
Just because it doesn't fit your project doesn't mean it's useless for everyone else. Your 90% of projects aren't other people's 90% of projects.
SSR was just an example. It's a valid solution, my point is that it's now yet an extra workaround to a problem we created in the first place.
Websites were SSR'd by default back in the day, the backend (with PHP or whatever you had on there) generates some HTML that the browser displayed. Then we decided that wasn't cool anymore and went through this whole clusterfuck of SPAs to justify cool kids' careers and now we're going back full-circle to a way more complex solution with more moving parts of doing exactly what we implicitly had 2 decades ago because we realised cool kids' careers had negative impacts in terms of page load performance.
Websites were SSR'd by default back in the day, the backend (with PHP or whatever you had on there) generates some HTML that the browser displayed. Then we decided that wasn't cool anymore and went through this whole clusterfuck of SPAs to justify cool kids' careers and now we're going back full-circle to a way more complex solution with more moving parts of doing exactly what we implicitly had 2 decades ago because we realised cool kids' careers had negative impacts in terms of page load performance.
But SSR isn't a core requirement for many applications. Nor is it necessary to build out a purely javascript based stack on the server side to get SSR with a shared React client codebase.
> Then we decided that wasn't cool anymore and went through this whole clusterfuck of SPAs to justify cool kids' careers and now we're going back full-circle to a way more complex solution with more moving parts of doing exactly what we implicitly had 2 decades ago because we realised cool kids' careers had negative impacts in terms of page load performance.
I really don't think the author of most of the tooling in the ES based javascript ecosystem are "cool kids trying to justify their careers". If you actually think that, take a look at the github profiles of some of the contributors for many of these repos. There's a ton of smart people working on these tools. They're not chasing trends. Sometimes complex problems require complex solutions. Sometimes they don't. It really depends on your project. Bemoaning the amount of options available seems like a waste of time.
> Then we decided that wasn't cool anymore and went through this whole clusterfuck of SPAs to justify cool kids' careers and now we're going back full-circle to a way more complex solution with more moving parts of doing exactly what we implicitly had 2 decades ago because we realised cool kids' careers had negative impacts in terms of page load performance.
I really don't think the author of most of the tooling in the ES based javascript ecosystem are "cool kids trying to justify their careers". If you actually think that, take a look at the github profiles of some of the contributors for many of these repos. There's a ton of smart people working on these tools. They're not chasing trends. Sometimes complex problems require complex solutions. Sometimes they don't. It really depends on your project. Bemoaning the amount of options available seems like a waste of time.
I never said the authors of big JS projects weren't smart. In fact, anyone that manages to keep their sanity in that environment is by definition smarter than me.
I however stand by my words that most React/Vue/Angular front-end developers in most companies are absolutely unnecessary and are actively detrimental to the project by introducing complexity to justify their position.
Most projects do not have any requirements like real-time UIs that would justify a front-end app and will be just fine with a "boring" backend-rendered UI with some HTML, CSS & forms and will automatically avoid a horde of problems like syncing authentication between your backend & frontend, having to manage a separate build pipeline, server for SSR, etc.
I however stand by my words that most React/Vue/Angular front-end developers in most companies are absolutely unnecessary and are actively detrimental to the project by introducing complexity to justify their position.
Most projects do not have any requirements like real-time UIs that would justify a front-end app and will be just fine with a "boring" backend-rendered UI with some HTML, CSS & forms and will automatically avoid a horde of problems like syncing authentication between your backend & frontend, having to manage a separate build pipeline, server for SSR, etc.
> I however stand by my words that most React/Vue/Angular front-end developers in most companies are absolutely unnecessary and are actively detrimental to the project by introducing complexity to justify their position.
I strongly disagree; most of the projects that I worked on a decade ago that lasted more than a few months ended up with ad-hoc frameworks or conventions implemented in vanilla JS or jQuery that varied wildly in quality and changed frequently through the lifespan of the project. In my experience React/Vue/Angular with their generally well engineered and thought-out principles have resulted in a huge boon for productivity for long term projects in a team environment.
> Most projects do not have any requirements like real-time UIs
Whose "most projects" are we talking about here? Yours?
I strongly disagree; most of the projects that I worked on a decade ago that lasted more than a few months ended up with ad-hoc frameworks or conventions implemented in vanilla JS or jQuery that varied wildly in quality and changed frequently through the lifespan of the project. In my experience React/Vue/Angular with their generally well engineered and thought-out principles have resulted in a huge boon for productivity for long term projects in a team environment.
> Most projects do not have any requirements like real-time UIs
Whose "most projects" are we talking about here? Yours?
> Whose "most projects" are we talking about here?
Go on a job board, search for React/Vue/Your-Favorite-SPA-framework, go to their website and then see if there are any features that would actually justify an SPA.
Some examples: the Airbnb website, the New Reddit, etc.
Go on a job board, search for React/Vue/Your-Favorite-SPA-framework, go to their website and then see if there are any features that would actually justify an SPA.
Some examples: the Airbnb website, the New Reddit, etc.
I would use reddit as a counter example.
Sure some the new features could be built without an SPA, but it would be much harder to do so.
They have a full wysgi for theming built in, a real time chat app, a video sharing app, multiple messaging platforms, and methods of bundling multiple subreddits together.
They added all this really fast, due to the nature of the platform being an SPA.
I have the same issue at work. Any given feature in isolation could be done simply as a jQuery plugin, but together the only way to make it seamless is an SPA.
They have a full wysgi for theming built in, a real time chat app, a video sharing app, multiple messaging platforms, and methods of bundling multiple subreddits together.
They added all this really fast, due to the nature of the platform being an SPA.
I have the same issue at work. Any given feature in isolation could be done simply as a jQuery plugin, but together the only way to make it seamless is an SPA.
Did you not compare how much faster & more usable their old platform is compared to the new one? The new one is painful to use.
It used to be true. Their first few months of the SPA was really rough on the UX front, but it really improved since then.
They have a good design staff, but there was so many minor decisions made over the years that no knew exactly what was a necessary feature of the UI and what was just fluff.
They needed some real world testing to get a better design.
They have a good design staff, but there was so many minor decisions made over the years that no knew exactly what was a necessary feature of the UI and what was just fluff.
They needed some real world testing to get a better design.
Relatedly:
If we don't adopt a framework we end up building one - increasingly of a patchwork of pieces fitting a bit roughly together.
If we don't adopt a framework we end up building one - increasingly of a patchwork of pieces fitting a bit roughly together.
"I hate that React needs a server for SSR. Instead I want a simple setup with a server for SSR."
SSR just seems like tail chasing, but this time around there is no mature server-side framework (like Django, Laravel, Rails). Maturity, ecosystem cohesion, and higher level abstractions are all casualties along the trail of abandoned work in the name of "scalability" and "modernity".
Hate to break it to you, but servers and server-side rendering existed before React.
Sounds like you're blaming good tools instead of bad developers.
Sounds like you're blaming good tools instead of bad developers.
There is no world where a tool or language for which you need hundreds of megabytes of unknown untrusted dependencies of dubious quality is considered a good tool.
[deleted]
...what? He was bemoaning React making things far more difficult than they need to be. And I think that’s a fair assessment of the situation. There’s a minimum overhead to maintaining a modern js app that is far higher than maintaining say, a Rails frontend. And it’s more costly for every change.
Rails and React are in no way comparable. They solve entirely different problems.
He's saying that there is client side rendering and now there needs to _also_ be server side rendering to compensate for its shortcomings.
There doesn't need to be server-side rendering to use React. There also doesn't need to be client-side rendering to use React.
Besides, a combo of PHP backend codebase and a jQuery frontend codebase has many more shortcomings than a single React codebase.
Besides, a combo of PHP backend codebase and a jQuery frontend codebase has many more shortcomings than a single React codebase.
> And it pulls hundreds of megabytes of shit behind the scenes with god knows what vulnerabilities & backdoors
I assume you roll your own OS then?
I assume you roll your own OS then?
Preact is like 5KB.
You do realise that 5KB is bigger than most text content you'd ever display on a webpage? You know how many things can go wrong when trying to download 5KB on flaky public Wi-Fi or overloaded cellular connection? And you're telling me it is no big deal to be loading that with no actual benefit to the user?
Sorry but 5kb is absolutely nothing for today's Internet connections, public WiFi or overloaded cellular connection or something else, especially if it's provided by a cdn. Yes, it is absolutely no big deal to be loading 5kb. Come on, be serious.
The problem is not the CDN, it's the last mile. You seriously overestimate public Wi-Fi and shit cellular networks; there are times where a simple HTTP request returning dozens of bytes of text will fail. In these moments every byte matters and personally if I'm going to make my user download 5kb of data I will make sure it's content they care about, not a JS framework.
Let's take the example of London Underground's Wi-Fi. It's only available at platforms, not while the train is travelling between stations. When the train arrives into the station it will stay there around 10 seconds. 5 seconds of those are wasted by the phone finding the network and authenticating to it, which means you've already got only 5 seconds before the train goes away and the connection drops off. During those 5 seconds you have lots of apps in the background (push, e-mail sync, background app refresh, etc) that are all fighting for around 1Mbps of bandwidth.
There's also the issue of failing gracefully. If CSS or image loading fails the browser will still display the bare HTML and the user will still have their content in a consumable format. If JS fails to load in an SPA the page is unusable and often shows just a blank screen. If SPA-initiated requests fail it's up to the developer to handle the exception and offer the user a way to retry instead of just giving up and waiting for a page reload.
Let's take the example of London Underground's Wi-Fi. It's only available at platforms, not while the train is travelling between stations. When the train arrives into the station it will stay there around 10 seconds. 5 seconds of those are wasted by the phone finding the network and authenticating to it, which means you've already got only 5 seconds before the train goes away and the connection drops off. During those 5 seconds you have lots of apps in the background (push, e-mail sync, background app refresh, etc) that are all fighting for around 1Mbps of bandwidth.
There's also the issue of failing gracefully. If CSS or image loading fails the browser will still display the bare HTML and the user will still have their content in a consumable format. If JS fails to load in an SPA the page is unusable and often shows just a blank screen. If SPA-initiated requests fail it's up to the developer to handle the exception and offer the user a way to retry instead of just giving up and waiting for a page reload.
As someone who used to commute through London on the tube and knows the underground wifi very well, you take on board the limitations of the connection. And you know the connection is going to fluctuate so you're not going to be doing anything serious.
Broken images and incorrectly loaded CSS can also break pages and make them unusuable so where do we draw the line?
I do get your point but on the other hand many sites are using JS frameworks for good reason and 5kb is absolutely nothing to improve the user experience. You really can't complain about the size of a 5kb javascript file in this day and age otherwise let's just revert back to HTML 2 or 3 to cater for all edge cases.
Broken images and incorrectly loaded CSS can also break pages and make them unusuable so where do we draw the line?
I do get your point but on the other hand many sites are using JS frameworks for good reason and 5kb is absolutely nothing to improve the user experience. You really can't complain about the size of a 5kb javascript file in this day and age otherwise let's just revert back to HTML 2 or 3 to cater for all edge cases.
Now you're just arguing for the sake of arguing. I get the general rant against huge bulky libraries, but you're picking the wrong hill to die on for 5kb.
Google's logo, one word, 4 colors, is 14kb.
To have a library that gives you a better foundation to build a website on be 5 (actually 3) kb? In what universe is that a bad thing?
Google's logo, one word, 4 colors, is 14kb.
To have a library that gives you a better foundation to build a website on be 5 (actually 3) kb? In what universe is that a bad thing?
This website's favicon is 7.3kb. What kind of weird edge case are you working for?
That is less data than the logo will take up, and is also less data than, e.g., the raw text in this comments section (compressed with brotli). With proper caching policy, the code bundle also only needs to be downloaded once.
jQuery is 80kb. How is that better than 5kb?
In a lot of cases (especially in today's modern JS and browsers) you don't need jQuery either.
Does it download 200MB of tools? (Seriously asking; I've contributed to some React apps but have made one from scratch never).
Create-react-app is pretty heavy, because it includes support for things you may not need or want (css modules, typescript, etc).
Putting together your own light-weight system isnt hard if you are familiar with the problems these tools solve, but unless you have a site so simple that it shouldn't use react anyway, you'll want the power and features that these tools can provide (automatic source splitting for lazy-loading code on route changes, sane management of language files for internationalization, extensive linting rules for even non-js things like accessibility features in html / jsx, automatic image optimizatuon, etc).
Putting together your own light-weight system isnt hard if you are familiar with the problems these tools solve, but unless you have a site so simple that it shouldn't use react anyway, you'll want the power and features that these tools can provide (automatic source splitting for lazy-loading code on route changes, sane management of language files for internationalization, extensive linting rules for even non-js things like accessibility features in html / jsx, automatic image optimizatuon, etc).
I prefer to just write raw JavaScript, and as little as possible.
Dokku gets an honorable mention, as it makes deployment as simple as `git push dokku master`:
http://dokku.viewdocs.io/dokku/
Dokku also uses(Heroku) buildpacks, which are becoming standardized:
https://buildpacks.io/
http://dokku.viewdocs.io/dokku/
Dokku also uses(Heroku) buildpacks, which are becoming standardized:
https://buildpacks.io/
I agree with your goal. Have you looked into Elixir/Phoenix? Phoenix is a great server-side web framework, and with the recent addition of Phoenix LiveView you can do really nice rich client side stuff, but all written server-side in Elixir.
LiveView is an alternate architecture to intercooler.js but with the same goal. There is a standard JS bundle that goes to the client that opens a websocket to the server. You annotate HTML tags (like intercooler) and then handle the events on the server. This is all abstracted away though so you end up writing a controller that looks a lot like a normal server side rendered page.
LiveView is an alternate architecture to intercooler.js but with the same goal. There is a standard JS bundle that goes to the client that opens a websocket to the server. You annotate HTML tags (like intercooler) and then handle the events on the server. This is all abstracted away though so you end up writing a controller that looks a lot like a normal server side rendered page.
Intercooler js looks really cool! Do you have any suggestions for adding transition animations? E.g. to add smooth in/out for AJAX returned content.
You can use CSS for transition animations. Look for “CSS-Based Indicators” in the docs.
I'm enjoying developing Django apps with Wagtail CMS:
https://wagtail.io
I have had a great development experience. The Wagtail core team are very active and helpful.
https://wagtail.io
I have had a great development experience. The Wagtail core team are very active and helpful.
Intercooler looks neat. I couldn't find anything on their site about supported browsers though.
It depends on jQuery and if you use history support it will need localStorage, so pretty broad browser support.
Ironic that intercoolerjs.org is missing functionality unless you allow scripts from code.jquery.com
Not sure about that. I simply include jquery then intercooler (both loaded from my server) and then it is off to the races...
> Who Should Avoid Snowpack?
> - Anyone who loves tooling-heavy development! This isn’t sarcastic, I promise! By dropping the bundler, you can’t do the magic that Webpack is famous for. Using import to load CSS, Images, and other non-JS resources is non-standard and unsupported in the browser (for now). You may appreciate a dev environment that is true to what standard JavaScript browsers support. Or, you may find this annoying.
---
I like that they make this a point, and I'm very much in the "let's not overload the standards" camp so I appreciate this as a feature, not a bug. This convinces me to give this tool a go!
> - Anyone who loves tooling-heavy development! This isn’t sarcastic, I promise! By dropping the bundler, you can’t do the magic that Webpack is famous for. Using import to load CSS, Images, and other non-JS resources is non-standard and unsupported in the browser (for now). You may appreciate a dev environment that is true to what standard JavaScript browsers support. Or, you may find this annoying.
---
I like that they make this a point, and I'm very much in the "let's not overload the standards" camp so I appreciate this as a feature, not a bug. This convinces me to give this tool a go!
The top comments are all about the complexity of front ends nowadays and X and Y comparison.
But they're missing the point, this is a really good idea.
But they're missing the point, this is a really good idea.
Consider the series of bad decisions that allowed such complexity to ooze in the first place. It all eventually boils down to developers putting their needs and concerns ahead of the product/user. I am not convinced this new tool will solve for bad/undisciplined developers.
I used to use 1000 NPM packages as a sarcastic example about bad decisions and death by dependency overkill then I installed Angular which pulls in 1100 packages alone. The end user doesn’t care about your framework choice, favorite language, tech stack, or build process. They just know your application is slow, clumsy, and riddled with defects.
I used to use 1000 NPM packages as a sarcastic example about bad decisions and death by dependency overkill then I installed Angular which pulls in 1100 packages alone. The end user doesn’t care about your framework choice, favorite language, tech stack, or build process. They just know your application is slow, clumsy, and riddled with defects.
This is really exciting to me. I've been meaning to try and get my head around how to start using ES modules with modern JavaScript stuff but it's tough because pretty much every tutorial assumes you'll be using Webpack. Snowpack looks like it might be the tool I've been missing.
I would also check out es-dev-server[1] from the open-wc.org project.
It's basically just a static file server that can automatically rewrite bare module specifiers using Node module resolution. It's the minimal transform you can apply to npm-installed JS modules that import dependencies via package name.
Yes, you get a waterfall of loads during development, but I haven't had this slow things down in practice, and once you get to development you can use Rollup to bundle modules, but unlike Webpack, it can bundle to standard module output.
[1]: https://www.npmjs.com/package/es-dev-server
It's basically just a static file server that can automatically rewrite bare module specifiers using Node module resolution. It's the minimal transform you can apply to npm-installed JS modules that import dependencies via package name.
Yes, you get a waterfall of loads during development, but I haven't had this slow things down in practice, and once you get to development you can use Rollup to bundle modules, but unlike Webpack, it can bundle to standard module output.
[1]: https://www.npmjs.com/package/es-dev-server
Try https://hqjs.org/ It can do much more than that. It takes care of sass/ less, frameworks and polyfills
I was getting worried we haven't seen a new JS tool for a few minutes.
Question for people unhappy about JS tooling: what's stopping you from just using vanilla JS?
Not exactly unhappy but why vanilla? By using transpiler and bundler, you get to,
- Use better JS (TypeScript) to be sent as ES5 (down to IE6 supoort) without waiting for people to upgrade their browsers to the latest, which is forever.
- Upgrade to latest specified version of libraries without having have to check every site and download the min.js or change the script tag url manually and dependencies are resolved automatically.
- Get to use stuff like stylus which is already far better than CSS 3 syntax and again, no need to wait for people to upgrade their browsers.
- Bundle all JS and CSS as a single file (and place all the other assets like images at a specified location automatically), which can be cached for instant load from second page, unless your frontend code is so fat, a single file becomes too huge for it.
- If your server side is node.js, you get to use a completely same language (TypeScript) for backend and frontend.
- Use better JS (TypeScript) to be sent as ES5 (down to IE6 supoort) without waiting for people to upgrade their browsers to the latest, which is forever.
- Upgrade to latest specified version of libraries without having have to check every site and download the min.js or change the script tag url manually and dependencies are resolved automatically.
- Get to use stuff like stylus which is already far better than CSS 3 syntax and again, no need to wait for people to upgrade their browsers.
- Bundle all JS and CSS as a single file (and place all the other assets like images at a specified location automatically), which can be cached for instant load from second page, unless your frontend code is so fat, a single file becomes too huge for it.
- If your server side is node.js, you get to use a completely same language (TypeScript) for backend and frontend.
The problem is one of culture. A reliance on complicated tooling requires specialization to these tools, which slows down team building time.
I've rescued several projects where more time was spent on making the lives of the developers "easier" than actually solving the problems of the user. Bike shedding and navel gazing is a huge problem in our industry, even if we don't like to admit it.
I've rescued several projects where more time was spent on making the lives of the developers "easier" than actually solving the problems of the user. Bike shedding and navel gazing is a huge problem in our industry, even if we don't like to admit it.
If you build components that use other components, without using a bundler, you constantly have to remember/know what uses what to get things to load. This may sound like not a big deal, but it doesnt take long at all and suddenly you've got loading issues!
I'm hoping some sanity is brought to front-end development. I had a project which legitimately did require a slice of the site to be SPA. I didn't do the full site, just the piece that needed it. When I looked at using React I was confused that it seemingly didn't want me to actually write HTML. Maybe I misread something, but it seemed like it wanted me to return HTML from JavaScript...this made little sense to me. I ended up using VueJS because it was far easier to learn. It did the job.
Webpack certainly is confusing too. I did a side project with some webpack and es6 stuff. It was kinda fun, but man, front-end development has sucked forever. I remember back in the day having to fight with IE6. Here we are, thirteen fucking years later and shit seems to have gotten only MORE complex.
I look at server-side programming for comparison. PHP for instance certainly is more complex with some of the frameworks you can use now and of course composer. But those are WAY simpler than the shit I had to deal with when coding the front. I just don't understand how things have gotten more complex on the front-end, brutal.
It got me thinking about playing around with WebAssembly for building front-end applications. Maybe that doesn't fit all use-cases and maybe the grass is always greener, but I wonder if programming in sane ecosystem would be the sane thing to do...?
Put me in the camp that if there isn't a use-case slapping me in the face, choking me, and yelling at me to do a SPA then I'll avoid the shit like a plague. I'll just go with server-side render pages and sprinkle in some very basic jQuery as needed. I actually did that for a CRM two years ago and the thing is so damn simple to program in, because JavaScript is only used if it ACTUALLY provides a benefit to the user. There is a site-wide script that is maybe 100 lines of code. Then some page-specific things that load in stuff using RequireJS, but the most complex JS out of those is maybe 300 lines. The vast majority of the site doesn't really use much JavaScript. Just plain old MVC.
As always, please BURN YOUR JAVASCRIPT STICKERS.
Webpack certainly is confusing too. I did a side project with some webpack and es6 stuff. It was kinda fun, but man, front-end development has sucked forever. I remember back in the day having to fight with IE6. Here we are, thirteen fucking years later and shit seems to have gotten only MORE complex.
I look at server-side programming for comparison. PHP for instance certainly is more complex with some of the frameworks you can use now and of course composer. But those are WAY simpler than the shit I had to deal with when coding the front. I just don't understand how things have gotten more complex on the front-end, brutal.
It got me thinking about playing around with WebAssembly for building front-end applications. Maybe that doesn't fit all use-cases and maybe the grass is always greener, but I wonder if programming in sane ecosystem would be the sane thing to do...?
Put me in the camp that if there isn't a use-case slapping me in the face, choking me, and yelling at me to do a SPA then I'll avoid the shit like a plague. I'll just go with server-side render pages and sprinkle in some very basic jQuery as needed. I actually did that for a CRM two years ago and the thing is so damn simple to program in, because JavaScript is only used if it ACTUALLY provides a benefit to the user. There is a site-wide script that is maybe 100 lines of code. Then some page-specific things that load in stuff using RequireJS, but the most complex JS out of those is maybe 300 lines. The vast majority of the site doesn't really use much JavaScript. Just plain old MVC.
As always, please BURN YOUR JAVASCRIPT STICKERS.
These guys are vastly exaggerating the time it takes to update a dev environment on save. It’s usually ready before you switch back to the browser.
For large projects, especially ones with TypeScript, this is definitely not true from my experience. Not sure if this a tool that’s suitable for those large projects but just saying that it definitely is a problem that would be nice to solve.
Try https://hqjs.org/ it works with big projects and typescript as well as sass, less and frameworks.
I think this is cool, but it’s hard to do any development in the current ecosystem without a lot of the magic of webpack.
I can’t count the number of times the solution to a problem we had was described as ‘just add these lines of magic to your webpack config’.
I can’t count the number of times the solution to a problem we had was described as ‘just add these lines of magic to your webpack config’.
This project looks like http://vanilla-js.com/ to me. It's already possible to load modules without any library with <script type="module"...
Snowpack looks like it works with any 3rd party module, doesnt it? It looks like vanilla-js is more of a jquery style lib + optional addons?
You would definitly need http/2 to use this, I've tried using imports in vanillajs with supported browsers its sloooooooow. I do wonder whether you could leverage server push for this and whether that would help.
Use cases of front end are getting more and more complex so the tools are as well. One could argue that we are trying to do so much with a platform that offers so little by default. Maybe that's the inherent culprit. Don't know. I really prefer frontend dev to backend (when I started it was all the same really), but I have to admit frontend complexity can scale pretty fast.
There is an alternative that can do much more and require less effort. Check it out https://hqjs.org plus vscode plugin https://marketplace.visualstudio.com/items?itemName=hqjs.hq-...
The added value of build tools is that javascript are increasingly the assembly of the web and more of a compilation target than something you deal with natively (using the term loosely here since we are talking extensive interpreter and compiler hacks that are needed to make this interpreted language feel fast-ish).
With web assembly maturing, interacting with this mess is becoming increasingly optional. Also languages like typescript and kotlin that compile to javascript add layers of much needed sanity. IMHO any project not using that is doing it wrong at this point. I'm very aware that this is opinionated and even offensive to some but after 2 decades of "maybe this will fix it" type innovation in the javascript world, I have very little patience left for that. The less I'm exposed to that smelly pile of manure, the better IMHO.
So, my recommendation: avoid this tool and use a sensible compile, verify, test, minify, and package it up style tool chain like all the grown ups do these days. I agree, tools for this are very much a cluster-fuck in terms of complexity, lack of any sane defaults that are actually good enough, usability, and performance but they're better than nothing.
In an ideal world, you'd not have to download hundreds of MB of layers of tools around tools that try to fix and work around each other. But there's no good technical reason to skip using them entirely. There's no sane excuse to skip sanity checks, type checks, static code analysis and running tests (and designing such that you can actually do this in a sane way, which seems to be hard with JS). Skipping that is immature and irresponsible. I don't tolerate it in my own projects and have no patience for self styled full stack js ninjas claiming their code is fine. It's not anywhere near fine.
With web assembly maturing, interacting with this mess is becoming increasingly optional. Also languages like typescript and kotlin that compile to javascript add layers of much needed sanity. IMHO any project not using that is doing it wrong at this point. I'm very aware that this is opinionated and even offensive to some but after 2 decades of "maybe this will fix it" type innovation in the javascript world, I have very little patience left for that. The less I'm exposed to that smelly pile of manure, the better IMHO.
So, my recommendation: avoid this tool and use a sensible compile, verify, test, minify, and package it up style tool chain like all the grown ups do these days. I agree, tools for this are very much a cluster-fuck in terms of complexity, lack of any sane defaults that are actually good enough, usability, and performance but they're better than nothing.
In an ideal world, you'd not have to download hundreds of MB of layers of tools around tools that try to fix and work around each other. But there's no good technical reason to skip using them entirely. There's no sane excuse to skip sanity checks, type checks, static code analysis and running tests (and designing such that you can actually do this in a sane way, which seems to be hard with JS). Skipping that is immature and irresponsible. I don't tolerate it in my own projects and have no patience for self styled full stack js ninjas claiming their code is fine. It's not anywhere near fine.
Or use whatever tool is best for the task at hand. No need to overly complicated making a website if you don't need to transpile and combine a bunch of libraries. Even just use jQuery or plain JS with a minimal backend if that's all you need for a simple website.
Also, my guess is JS still predominates as the web language being used by developers, provided that React syntax is included.
Also, my guess is JS still predominates as the web language being used by developers, provided that React syntax is included.
Tbh parceljs does make bundling a lot better to deal with. For example, how would I integrate wasm using this?
But this is only for importing JS modules, right?
What about SASS, minification, etc?
What about SASS, minification, etc?
Try https://hqjs.org it takes care of everything like sass, less, typescript and polyfills.
It does minify when using the --optomize flag https://www.snowpack.dev/#optimizing-for-production
I am curious about SASS and other loaders too.
What can I do with Snowpack that I can't with a CDN?
They seem pretty orthogonal to me. Snowpack is about builds, CDN is about serving. You could serve snowpack built JS dependencies with a CDN.
You can leverage dependencies that are not published to a CDN, such as local dependency code.
Does it make sense to use it with svelte?
Although I've contributed to some React projects, the last time I had to do user-facing web frontend stuff was with the original Angular. Looking at this, I'm really glad I don't do frontend anymore.
I've touched some vue.js too, but I just hate the direction everything is going. These projects are just insanely complex. Component frameworks may be easier to develop with, but they add so much damn bloat and crazy amounts of tooling. I get frustrated enough with Jekyll and that's just a static content generator.
I really miss the simplicity of plain old jQuery and some backend.
I've touched some vue.js too, but I just hate the direction everything is going. These projects are just insanely complex. Component frameworks may be easier to develop with, but they add so much damn bloat and crazy amounts of tooling. I get frustrated enough with Jekyll and that's just a static content generator.
I really miss the simplicity of plain old jQuery and some backend.
Frontend over-complexity is exactly the problem that this is trying to solve for! You can think of this as a simple post-install tool that removes a huge chunk of the complexity (bundling) from your stack, without limiting what you can build.
If this direction of simplified web development is something you're interested in, you'll enjoy this post I wrote back when we started this project (and it was called @pika/web): "A Future Without Webpack" - https://www.pika.dev/blog/pika-web-a-future-without-webpack/
Disclaimer: I created Snowpack & Pika (pika.dev).
If this direction of simplified web development is something you're interested in, you'll enjoy this post I wrote back when we started this project (and it was called @pika/web): "A Future Without Webpack" - https://www.pika.dev/blog/pika-web-a-future-without-webpack/
Disclaimer: I created Snowpack & Pika (pika.dev).
I would have hoped with a focus on security that we'd be moving to front ends that run less untrusted code on the client.
I would use a framework that did the majority of its magic on the back end and emitted either zero code that needs to run on the client or completely gracefully degrades when the client refuses to run untrusted code.
Every day it feels more and more like the web is a tracking framework with the lowest effort content that will keep the cattle clicking than an actual platform that provides real value. Being able to switch off executing remote code but be left with a functioning web experience would go a long way to providing real user privacy, which is, of course, why I have zero hope of it actually happening.
I would use a framework that did the majority of its magic on the back end and emitted either zero code that needs to run on the client or completely gracefully degrades when the client refuses to run untrusted code.
Every day it feels more and more like the web is a tracking framework with the lowest effort content that will keep the cattle clicking than an actual platform that provides real value. Being able to switch off executing remote code but be left with a functioning web experience would go a long way to providing real user privacy, which is, of course, why I have zero hope of it actually happening.
Adding more tools to abstract and hide away the complexity doesn't actually make the complexity go away, though, does it? It doesn't make it easier to reason about the end result. Just hides it under a veneer.
I think what the guy you're responding to is after is similar to what I'd like to see: a front end that isn't composed of 20 years of hacks layered on top of each other because of poor initial choices.
I think what the guy you're responding to is after is similar to what I'd like to see: a front end that isn't composed of 20 years of hacks layered on top of each other because of poor initial choices.
That's whats so cool about this: Unlike Create React App or other "starter apps" that try to hide complexity from you, Snowpack actually removes that complexity entirely. If you didn't want to use a single other tool, you could use Snowpack to build a fully modern web app by shipping your source code directly to the browser (cue the "View Source" nostalgia :)
Luke Jacksonn is someone who's done some interesting work in this space with zero-build-tooling sites: https://perf.link - https://github.com/lukejacksonn/perflink
https://www.pika.dev is built with Babel and TypeScript, so it's not technically "zero-tooling", but we still get almost instant iteration by skipping a "bundle" step during development.
Luke Jacksonn is someone who's done some interesting work in this space with zero-build-tooling sites: https://perf.link - https://github.com/lukejacksonn/perflink
https://www.pika.dev is built with Babel and TypeScript, so it's not technically "zero-tooling", but we still get almost instant iteration by skipping a "bundle" step during development.
Even TypeScript having to compile down to JS for the browser just feels fundamentally wrong. Why write something in some new, domain-specific language that compiles down to an inferior language to run in the browser?
Hopefully with WASM we see the rise of client-side frameworks that bypass all of this bullshit entirely and give us a clean slate to develop on that picks up the best of the 90s low-code projects and makes them cloudworthy. There's no reason why 99% of the UI that most sites need isn't just assembled from a nice list of stock UI widgets.
Disclaimer, am old and miss 90s desktop apps
Hopefully with WASM we see the rise of client-side frameworks that bypass all of this bullshit entirely and give us a clean slate to develop on that picks up the best of the 90s low-code projects and makes them cloudworthy. There's no reason why 99% of the UI that most sites need isn't just assembled from a nice list of stock UI widgets.
Disclaimer, am old and miss 90s desktop apps
Gotta nitpick here.
JS _is_ the native language for browsers. Therefore, it's reasonable to target it.
While it's entirely possible to compile your language interpreter of choice to WASM and run that in a browser, you're now in sort of the reverse position that folks complain about with Electron: adding tons of extra bloat, overhead, and complexity, just to duplicate some other runtime environment into a place it wasn't particularly intended to be used in the first place.
In addition, with most "compile other language to WASM" demos I've seen so far, they end up just drawing things on canvas, thus losing all the accessibility aspects that are built into the DOM already. (Yes, I know WASM has some DOM interop abilities and more coming, but that's not generally what I'm seeing done atm.)
What's _really_ needed is way better UI elements built directly into HTML, but those are sadly lacking.
JS _is_ the native language for browsers. Therefore, it's reasonable to target it.
While it's entirely possible to compile your language interpreter of choice to WASM and run that in a browser, you're now in sort of the reverse position that folks complain about with Electron: adding tons of extra bloat, overhead, and complexity, just to duplicate some other runtime environment into a place it wasn't particularly intended to be used in the first place.
In addition, with most "compile other language to WASM" demos I've seen so far, they end up just drawing things on canvas, thus losing all the accessibility aspects that are built into the DOM already. (Yes, I know WASM has some DOM interop abilities and more coming, but that's not generally what I'm seeing done atm.)
What's _really_ needed is way better UI elements built directly into HTML, but those are sadly lacking.
Now that web components are maturing, is there any working group that is chartered to improve the standard HTML UI compnent library?
There's been some discussion of making things like a virtual scroller available under an "std" global namespace [0], and the Chrome/Edge teams recently did a refresh of just the visual appearance of the standard built-in HTML inputs [1] (which, frankly, I think look even worse now).
Beyond that, nothing meaningful is happening. Even the input types defined as part of the HTML5 spec are still barely supported [2], and if browsers can't manage to implement decent date/time/range/color inputs, there's no way of getting more complex components designed and standardized.
Of course, the other aspect of that is, anything that is part of the web API is there forever, which means bugs and mistakes aren't really fixable. So, there's some benefits to having a purely community-driven ecosystem instead.
[0] https://github.com/WICG/virtual-scroller
[1] https://blogs.windows.com/msedgedev/2019/10/15/form-controls...
[2] https://www.smashingmagazine.com/2019/01/html5-input-types/
Beyond that, nothing meaningful is happening. Even the input types defined as part of the HTML5 spec are still barely supported [2], and if browsers can't manage to implement decent date/time/range/color inputs, there's no way of getting more complex components designed and standardized.
Of course, the other aspect of that is, anything that is part of the web API is there forever, which means bugs and mistakes aren't really fixable. So, there's some benefits to having a purely community-driven ecosystem instead.
[0] https://github.com/WICG/virtual-scroller
[1] https://blogs.windows.com/msedgedev/2019/10/15/form-controls...
[2] https://www.smashingmagazine.com/2019/01/html5-input-types/
What framework-agnostic HTML UI component library would you recommend? Most of the options I have seen either have framework-specific dependencies (React, Polymer, Aurelia, Angular, Vue) or are just low-level frameworks for building your own UI/web components.
Any UI library based on web components is your best bet for a 'framework-less' solution. Some more popular ones are:
- Material Design Web Components, https://github.com/material-components/material-components-w...
- Vaadin, https://vaadin.com/components
- UI5, https://sap.github.io/ui5-webcomponents/
- Material Design Web Components, https://github.com/material-components/material-components-w...
- Vaadin, https://vaadin.com/components
- UI5, https://sap.github.io/ui5-webcomponents/
There's a video from the latest Chrome Dev Summit on this very topic https://www.youtube.com/watch?v=ZFvPLrKZywA&feature=youtu.be
Are you actually going to write WASM by hand? Or are going to use a ... you know... compiler to generate the WASM from your source file? If you compiled Typescript to WASM instead of js, would that somehow be a different development experience?
1. WASM is not a replacement for JS. You still need javascript glue code to actually load and run the WASM.
2. You're not writing WASM by hand, exactly like how you don't write assembly by hand. There's little semantic difference of compiling from <your_language> to WASM versus transpiling from typescript to javascript.
3. Typescript isn't really that new.
2. You're not writing WASM by hand, exactly like how you don't write assembly by hand. There's little semantic difference of compiling from <your_language> to WASM versus transpiling from typescript to javascript.
3. Typescript isn't really that new.
I and others applaud the effort.
We are just saying that we'd appreciate something that removes the need for webpack et al.
I'd personally kill for a much simpler (and faster!) webpack.
We are just saying that we'd appreciate something that removes the need for webpack et al.
I'd personally kill for a much simpler (and faster!) webpack.
This does! :D
This looks really great. Kudos!
A question for you: I see the site mentions using Snowpack with Vue but there's no guide like there is for React. Can you point me at some sort of "getting started" guide, blog post, or example repo for using Snowpack with Vue?
A question for you: I see the site mentions using Snowpack with Vue but there's no guide like there is for React. Can you point me at some sort of "getting started" guide, blog post, or example repo for using Snowpack with Vue?
Sorry, which tool? Snowpack?
Yup, from the tl;dr on the site:
> TL;DR - Snowpack removes the need for bundlers (Webpack, Parcel, Rollup) in a traditional application build process by leveraging the ESM syntax you're already writing. Keep using your favorite web frameworks (React, Preact, Vue, Svelte) & build tools (Babel, TypeScript).
> TL;DR - Snowpack removes the need for bundlers (Webpack, Parcel, Rollup) in a traditional application build process by leveraging the ESM syntax you're already writing. Keep using your favorite web frameworks (React, Preact, Vue, Svelte) & build tools (Babel, TypeScript).
Then I could see myself trying Snowpack. Thanks for the clarification.
Why the name change? I was confused because I thought this was a competitor to Pika until I saw your comment.
Unpopular opinion: It isn't that bad. If you understand the purpose of a bundler and you understand the purpose of a transpiler, it's not difficult to understand how to put two and two together. You, for example, write ES6, you use babel to transpile to ES5, and webpack collapses all the require(...) calls into a smaller set of files (maybe even a single file, depending on your configuration).
It's all well documented, so if you need further details, there's nothing magic about these tools.
If you really don't want to be bothered with it, just use create react app, vue cli, or angular cli. Some people aren't that interested tooling, I get it.
It's all well documented, so if you need further details, there's nothing magic about these tools.
If you really don't want to be bothered with it, just use create react app, vue cli, or angular cli. Some people aren't that interested tooling, I get it.
> write ES6, you use babel to transpile to ES5
If you have the luxury to only care about modern browsers, do you need to bother transpiling? Every modern browser supports ES6 natively.
> and webpack collapses all the require(...) calls into a smaller set of files
Also less of an issue if you're using http/2 or http/3.
Is there a "preview of the future" framework out there that people can use if they want to see what a world looks like that doesn't have to work around old browsers?
If you have the luxury to only care about modern browsers, do you need to bother transpiling? Every modern browser supports ES6 natively.
> and webpack collapses all the require(...) calls into a smaller set of files
Also less of an issue if you're using http/2 or http/3.
Is there a "preview of the future" framework out there that people can use if they want to see what a world looks like that doesn't have to work around old browsers?
The whole point of this snowpack framework is that if you only care about modern browsers, everything is clean and collapsed. No compilation needed of your application code.
There are people making applications with requirements where we have to support the legacy browsers, unfortunately. That's how Enterprise goes (but even large consumer-facing apps have the same requirements too, I would be shocked if Facebook "didn't work" on IE 11 today).
In my particular case, my infrastructure team will not, and has no plans on, enabling HTTP/2 in our upstream servers. The joy of application development at scale. You can't get everything you want, unless you control it all. Things are too distributed for me to practically sell the team on HTTP/2.
In my particular case, my infrastructure team will not, and has no plans on, enabling HTTP/2 in our upstream servers. The joy of application development at scale. You can't get everything you want, unless you control it all. Things are too distributed for me to practically sell the team on HTTP/2.
I understand that, and I know that such an approach wouldn't work for everyone. But it's worth looking at what the future could look like.
Hire an expensive consultant to tell them what they need to hear. I’m sure if they pay $100k for the privilege of hearing they need HTTP/2 they’ll be more receptive to the need.
I am an expensive consultant. My advice is skip HTTP/2. Either wait for HTTP/3 to ditch TCP or start inlining resources into single HTML documents to reduce round trips.
What motivates that advice?
I'm definitely looking forward to HTTP/3, but I anticipate HTTP/3 having more problems with adoption due to overzealous firewalls and UDP blocking. I expect a longer tail of "I can't use HTTP/3" clients than "I can't use HTTP/2" clients, which means it'll be longer before you can reasonably count on it for performance optimization.
I'm definitely looking forward to HTTP/3, but I anticipate HTTP/3 having more problems with adoption due to overzealous firewalls and UDP blocking. I expect a longer tail of "I can't use HTTP/3" clients than "I can't use HTTP/2" clients, which means it'll be longer before you can reasonably count on it for performance optimization.
Maybe you do but I don't. I spent a week learning Webpack four years ago and it's been paying dividends ever since. 99% of my job is building features, <1% is fuddling with tooling and configuration.
If the hard part of your project is setting it up the tools you've picked are too complex for the problem you're trying to solve.
If the hard part of your project is setting it up the tools you've picked are too complex for the problem you're trying to solve.
Of all the bundlers and build systems, Webpack has been the most productive for me by far. We had a heck of a time with a couple of bundlers we were trying out a few months ago, and when we switched to Webpack, all of the things we struggled with on the previous bundlers came together seamlessly in less than half an hour.
Try https://hqjs.org/ it can do much more with much less effort. It supports all popular frameworks out of the box plus metalanguages like typescript and scss, and it takes care of polyfills
> If the hard part of your project is setting it up the tools you've picked are too complex for the problem you're trying to solve.
Sure, but what tooling choice do we have? Webpack is pretty much a standard and is expected almost everywhere, with rollup and parcel used here and there.
Sure, but what tooling choice do we have? Webpack is pretty much a standard and is expected almost everywhere, with rollup and parcel used here and there.
Your choice is to not build an SPA. There's nothing wrong with HTML, jQuery, and Bootstrap. I'm fairly convinced most JavaScript fatigue is the result of trying to build very simple web pages with tools designed for 10k+ LoC SPAs.
Part of the time you're right. But I do like to dabble with JS again -- after being backender only for years -- and I want to future-proof my work (if at all possible in the JS land).
And I throw my hands in the air every time. Stuff like React or Vue generators seem to work fine but then I am left confused what do all the files do and why don't I have a stricter control over what gets pulled inside the project.
And I throw my hands in the air every time. Stuff like React or Vue generators seem to work fine but then I am left confused what do all the files do and why don't I have a stricter control over what gets pulled inside the project.
Use the tools you understand to solve the problems at hand. The ecosystem wasn't built to optimize convenience for hobbyists, these tools have evolved over time to address specific needs, if you can't articulate the specific needs being addressed by every component in your asset pipeline, you shouldn't be using them.
Fair to a degree, I guess. Still, in the years during which I didn't work with JS, I picked like 5 other languages and even though they weren't exactly beginner-friendly I still managed rather quickly.
JS though, always has been the exception. I understand what transpiling and bundling and minifying etc. are. But the tooling is somehow... don't know, hard to work with. And sometimes you get errors even in newly generated projects.
It's indeed hard to articulate the problems but that’s because I've only done isolated toe-dipping for a while now, not because I don’t understand something. JS could still use shortcuts during development, a la the Parcel tool, and turn that into an universal approach in all of its ecosystem.
JS though, always has been the exception. I understand what transpiling and bundling and minifying etc. are. But the tooling is somehow... don't know, hard to work with. And sometimes you get errors even in newly generated projects.
It's indeed hard to articulate the problems but that’s because I've only done isolated toe-dipping for a while now, not because I don’t understand something. JS could still use shortcuts during development, a la the Parcel tool, and turn that into an universal approach in all of its ecosystem.
> It's indeed hard to articulate the problems but that’s because I've only done isolated toe-dipping for a while now, not because I don’t understand something
Exactly. I don't think your proficiency as a developer is in question, the issue is that your approach is backwards. You're searching for a reason to justify why you should use these tools, rather than trying to build a piece of software with specific requirements and then determining which tools facilitate that goal.
> JS could still use shortcuts during development, a la the Parcel tool, and turn that into an universal approach in all of its ecosystem
The ecosystem already represents millions of developer hours distilled into "shortcuts" that allow developers to achieve capabilities that are very impractical without those tools. The idea of a "universal approach" in open-source makes no sense, people use the tools that best solve the problems they encounter, there will never be a one-size fits all solution, you have to understand the problem you're facing in order to pick the correct tool for the job.
Exactly. I don't think your proficiency as a developer is in question, the issue is that your approach is backwards. You're searching for a reason to justify why you should use these tools, rather than trying to build a piece of software with specific requirements and then determining which tools facilitate that goal.
> JS could still use shortcuts during development, a la the Parcel tool, and turn that into an universal approach in all of its ecosystem
The ecosystem already represents millions of developer hours distilled into "shortcuts" that allow developers to achieve capabilities that are very impractical without those tools. The idea of a "universal approach" in open-source makes no sense, people use the tools that best solve the problems they encounter, there will never be a one-size fits all solution, you have to understand the problem you're facing in order to pick the correct tool for the job.
> You're searching for a reason to justify why you should use these tools, rather than trying to build a piece of software with specific requirements and then determining which tools facilitate that goal.
I realise that and you are correct. I am just wondering: is there a way for me to ascertain if JS ecosystem has calmed down and is more friendly to productive programmer workflow, or is still pretty much the Wild West and everybody does whatever they like and there are not many widely accepted good practices for JS project management?
It does seem however that I should just pick up a project idea from, say, RosettaGIT or TodoMVC, and try and implement them with a few different JS stacks (React / PReact / Vue / Svelte come to mind) and gather my own info.
I realise that and you are correct. I am just wondering: is there a way for me to ascertain if JS ecosystem has calmed down and is more friendly to productive programmer workflow, or is still pretty much the Wild West and everybody does whatever they like and there are not many widely accepted good practices for JS project management?
It does seem however that I should just pick up a project idea from, say, RosettaGIT or TodoMVC, and try and implement them with a few different JS stacks (React / PReact / Vue / Svelte come to mind) and gather my own info.
> is there a way for me to ascertain if JS ecosystem has calmed down and is more friendly to productive programmer workflow
I would reject the framing that suggests the ecosystem is not geared towards productivity. These frameworks allow developers to be more productive than ever, as I noted in another thread, these tools have been a proven success across every major tech company with a front-end presence, it's not just hype, there are demonstrable results.
> everybody does whatever they like and there are not many widely accepted good practices for JS project management
There are many widely accepted best practices, but thats a huge topic. Use of linters like eslint can ensure hundreds of best practices are enforced in your project, and type systems like flow/typescript are an indisputable boon to long-term software maintenance. A software project with types is always much easier to maintain than one without, and the upfront cost of thinking about your data structures in advance of writing your business logic is the technical debt equivalent of not carrying a month to month balance on your credit cards.
> I should just pick up a project idea from, say, RosettaGIT or TodoMVC, and try and implement them with a few different JS stacks (React / PReact / Vue / Svelte come to mind)
This is a great idea. Everyone has different opinions about these frameworks but they're all productive.
In my personal opinion, React is the best of those options because the JSX code-as-markup paradigm means that your application variables interpolate with your views seamlessly without the added complexity of a system for processing gigantic string templates with custom logic directives and custom template inclusion mechanisms. Svelte has some interesting new ideas with regard to preprocessing the views at build time that are pretty cool, but I still prefer React due to the string template thing I just mentioned. PReact is basically just a slimmer React, not much distinction in terms of the workflow. I find Vue to be the least appealing of the options you mentioned since it has poor TypeScript support and in most implementations relies heavily on string templates, but it is often regarded as the most accessible framework for newcomers. Those are just my personal opinions, I think any of those tools are solid and they all have beginner friendly options like create-react-app to help you get up and running quickly.
I would reject the framing that suggests the ecosystem is not geared towards productivity. These frameworks allow developers to be more productive than ever, as I noted in another thread, these tools have been a proven success across every major tech company with a front-end presence, it's not just hype, there are demonstrable results.
> everybody does whatever they like and there are not many widely accepted good practices for JS project management
There are many widely accepted best practices, but thats a huge topic. Use of linters like eslint can ensure hundreds of best practices are enforced in your project, and type systems like flow/typescript are an indisputable boon to long-term software maintenance. A software project with types is always much easier to maintain than one without, and the upfront cost of thinking about your data structures in advance of writing your business logic is the technical debt equivalent of not carrying a month to month balance on your credit cards.
> I should just pick up a project idea from, say, RosettaGIT or TodoMVC, and try and implement them with a few different JS stacks (React / PReact / Vue / Svelte come to mind)
This is a great idea. Everyone has different opinions about these frameworks but they're all productive.
In my personal opinion, React is the best of those options because the JSX code-as-markup paradigm means that your application variables interpolate with your views seamlessly without the added complexity of a system for processing gigantic string templates with custom logic directives and custom template inclusion mechanisms. Svelte has some interesting new ideas with regard to preprocessing the views at build time that are pretty cool, but I still prefer React due to the string template thing I just mentioned. PReact is basically just a slimmer React, not much distinction in terms of the workflow. I find Vue to be the least appealing of the options you mentioned since it has poor TypeScript support and in most implementations relies heavily on string templates, but it is often regarded as the most accessible framework for newcomers. Those are just my personal opinions, I think any of those tools are solid and they all have beginner friendly options like create-react-app to help you get up and running quickly.
> These frameworks allow developers to be more productive than ever, as I noted in another thread, these tools have been a proven success across every major tech company with a front-end presence, it's not just hype, there are demonstrable results.
I am inclined to agree. I know things have been bad in the past -- that's why I exited JS and gave up my title as a full-stack dev -- but I am still left wondering if things can't get even better. I'll take your word for it that things are better than before because from occasional observations I reached the same conclusion.
> Use of linters like eslint can ensure hundreds of best practices are enforced in your project
Learned something very useful. Thank you!
> and type systems like flow/typescript are an indisputable boon to long-term software maintenance. A software project with types is always much easier to maintain than one without, and the upfront cost of thinking about your data structures in advance of writing your business logic is the technical debt equivalent of not carrying a month to month balance on your credit cards.
You'll never catch me disagreeing. That's why I am learning Rust and OCaml currently. Dynamic languages can be amazing -- Elixir is one example -- but there comes a point where you just need a much stricter compiler because you are otherwise chasing your own tail for weeks. So yeah, I am fully with you here. If I get back to JS it's definitely going to be proxied through TypeScript!
> In my personal opinion, React is the best of those options...
I have no idea for now. I get what you are saying and I also would base my choice on which lib supports TypeScript [better than others]. I just want lagless UIs in the cases where my projects absolutely positively need dynamism in the said UI.
I want something that works excellently even on an iPhone 4 / Galaxy S3 / Nokia 2.1. I am looking for minimal bundle sizes, least extra cruft carried, and speed.
Which JS lib/framework would you recommend? For now I don't intend on having complex UI or complex data bindings. But I'd also like to have to option in the future.
I am inclined to agree. I know things have been bad in the past -- that's why I exited JS and gave up my title as a full-stack dev -- but I am still left wondering if things can't get even better. I'll take your word for it that things are better than before because from occasional observations I reached the same conclusion.
> Use of linters like eslint can ensure hundreds of best practices are enforced in your project
Learned something very useful. Thank you!
> and type systems like flow/typescript are an indisputable boon to long-term software maintenance. A software project with types is always much easier to maintain than one without, and the upfront cost of thinking about your data structures in advance of writing your business logic is the technical debt equivalent of not carrying a month to month balance on your credit cards.
You'll never catch me disagreeing. That's why I am learning Rust and OCaml currently. Dynamic languages can be amazing -- Elixir is one example -- but there comes a point where you just need a much stricter compiler because you are otherwise chasing your own tail for weeks. So yeah, I am fully with you here. If I get back to JS it's definitely going to be proxied through TypeScript!
> In my personal opinion, React is the best of those options...
I have no idea for now. I get what you are saying and I also would base my choice on which lib supports TypeScript [better than others]. I just want lagless UIs in the cases where my projects absolutely positively need dynamism in the said UI.
I want something that works excellently even on an iPhone 4 / Galaxy S3 / Nokia 2.1. I am looking for minimal bundle sizes, least extra cruft carried, and speed.
Which JS lib/framework would you recommend? For now I don't intend on having complex UI or complex data bindings. But I'd also like to have to option in the future.
> For now I don't intend on having complex UI or complex data bindings. But I'd also like to have to option in the future.
I would go with the minimalist Vue setup. Write static HTML, add Vue as a script tag, and sprinkle in Vue components where you need complex JavaScript. This is the primary use case for which I recommend Vue.
I would go with the minimalist Vue setup. Write static HTML, add Vue as a script tag, and sprinkle in Vue components where you need complex JavaScript. This is the primary use case for which I recommend Vue.
> am just wondering: is there a way for me to ascertain if JS ecosystem has calmed down and is more friendly to productive programmer workflow, or is still pretty much the Wild West and everybody does whatever they like and there are not many widely accepted good practices for JS project management?
There are widely accepted good practices, but the domains in which they are widely accepted are narrower than “JavaScript development”.
Each major front-end framework is something of a community of its own (often with sub-communities), and there are others.
There are widely accepted good practices, but the domains in which they are widely accepted are narrower than “JavaScript development”.
Each major front-end framework is something of a community of its own (often with sub-communities), and there are others.
> and I want to future-proof my work (if at all possible in the JS land).
how often has this panned out for you?
how often has this panned out for you?
Never. Still looking for ways. JS ecosystem is immature.
You probably never maintained a codebase with 10k+ lines of jQuery.
You can however build extremely large applications in Vue/React without much of a sweat.
Try without them with jquery only and you'll hit some walls. You'd basically ending up by rolling your own stuff with something vaguely similar.
Sure you can do static pages all day, but the whole idea is maintaining state and stateful transitions.
Try without them with jquery only and you'll hit some walls. You'd basically ending up by rolling your own stuff with something vaguely similar.
Sure you can do static pages all day, but the whole idea is maintaining state and stateful transitions.
Trying to do anything more complex than a slider was a PITA with jQuery. Managing states, managing templates, trying to keep everything in sync, etc.
>> I've touched some vue.js too, but I just hate the direction everything is going.
I've had the exact same thoughts. For a long time, I was a big VueJS fan because of its simplicity and I could build really nice clean and fast apps without a bundler. When your app has few dependencies, bundling is overkill. For some personal projects, I didn't even bundle for production; still, it loaded faster and the user experience felt smoother than the vast majority of web applications that we have today.
Now I can see VueJS is moving towards TypeScript and forced bundling. It's beyond frustrating. It's refreshing to read comments like above because so few people are experienced enough to see it as a problem. There was a period in front end development a bit less than a decade ago when it felt like things where always getting better every year; bundlers were only used for production for some projects and HTTP2 was going to allow us to push scripts to the browser so that we wouldn't even need to bundle for production... The future was bright. Then Webpack came along and it became crazy popular, then suddenly people started bundling during development? WTF! Then CoffeeScript came along, added essentially no value at all but people were crazy about it, then transpiling and bundling during development became completely normal. I never thought I'd live to see the day that people would be debugging machine-mangled code. All the work that had been done before since the invention of the computer was about making machine code more readable for humans so this was a shocking reversal of progress.
Most younger people think that bundling is normal... Always existing kind of thing. They don't realize that bundling and transpilation is a massive hack that was meant to be temporary and really should never have existed.
Very experienced engineers from previous generations invested a lot of time and effort into making fast interpreters for dynamic languages like JavaScript so that people didn't have to wait for code to compile. I remember watching interviews with Google Engineers who worked on V8 thinking to myself how great it was that they were able to get interpreted JavaScript to almost match the performance of compiled languages like Java; that was a huge achievement. Waiting for the code to compile was considered a major problem back then; especially for front end web development. Let's face it, the underlying problems of front end development are trivial, but the ecosystem itself has turned simple problems into highly complex ones.
If you've used programming languages like C/C++ where you have to link static and dynamic libraries together, the value of a fast interpreted language is very clear and JavaScript fits the use case quite well. Front end development was never rocket science though it seems to be getting there.
Now people added a massive, highly complex and poorly thought out bundling and transpilation layer between the efficient browser engine and their web apps which essentially takes away all the value and efficiency that had been thoughtfully and painstakingly added to all the layers underneath since the dawn of time.
Then people start complaining about how bloated and bulky and difficult software development is, but before we can all realize that the answer is to throw out all the unnecessary crap that was added on top, some genius will come along out of nowhere with hot new technology which will add even more crap on top and which gives the illusion of solving the problems that people were complaining about but it will in fact cause new, even worse problems... and the cycle of bloat and disappointment will continue.
But at least we will all have more jobs... For a while.
I swear if this industry gets any more retarded, they'll be able to replace us with monkeys. Some genius with an MBA will figure out that same productivity with lower costs = higher profits.
I've had the exact same thoughts. For a long time, I was a big VueJS fan because of its simplicity and I could build really nice clean and fast apps without a bundler. When your app has few dependencies, bundling is overkill. For some personal projects, I didn't even bundle for production; still, it loaded faster and the user experience felt smoother than the vast majority of web applications that we have today.
Now I can see VueJS is moving towards TypeScript and forced bundling. It's beyond frustrating. It's refreshing to read comments like above because so few people are experienced enough to see it as a problem. There was a period in front end development a bit less than a decade ago when it felt like things where always getting better every year; bundlers were only used for production for some projects and HTTP2 was going to allow us to push scripts to the browser so that we wouldn't even need to bundle for production... The future was bright. Then Webpack came along and it became crazy popular, then suddenly people started bundling during development? WTF! Then CoffeeScript came along, added essentially no value at all but people were crazy about it, then transpiling and bundling during development became completely normal. I never thought I'd live to see the day that people would be debugging machine-mangled code. All the work that had been done before since the invention of the computer was about making machine code more readable for humans so this was a shocking reversal of progress.
Most younger people think that bundling is normal... Always existing kind of thing. They don't realize that bundling and transpilation is a massive hack that was meant to be temporary and really should never have existed.
Very experienced engineers from previous generations invested a lot of time and effort into making fast interpreters for dynamic languages like JavaScript so that people didn't have to wait for code to compile. I remember watching interviews with Google Engineers who worked on V8 thinking to myself how great it was that they were able to get interpreted JavaScript to almost match the performance of compiled languages like Java; that was a huge achievement. Waiting for the code to compile was considered a major problem back then; especially for front end web development. Let's face it, the underlying problems of front end development are trivial, but the ecosystem itself has turned simple problems into highly complex ones.
If you've used programming languages like C/C++ where you have to link static and dynamic libraries together, the value of a fast interpreted language is very clear and JavaScript fits the use case quite well. Front end development was never rocket science though it seems to be getting there.
Now people added a massive, highly complex and poorly thought out bundling and transpilation layer between the efficient browser engine and their web apps which essentially takes away all the value and efficiency that had been thoughtfully and painstakingly added to all the layers underneath since the dawn of time.
Then people start complaining about how bloated and bulky and difficult software development is, but before we can all realize that the answer is to throw out all the unnecessary crap that was added on top, some genius will come along out of nowhere with hot new technology which will add even more crap on top and which gives the illusion of solving the problems that people were complaining about but it will in fact cause new, even worse problems... and the cycle of bloat and disappointment will continue.
But at least we will all have more jobs... For a while.
I swear if this industry gets any more retarded, they'll be able to replace us with monkeys. Some genius with an MBA will figure out that same productivity with lower costs = higher profits.
> Now I can see VueJS is moving towards TypeScript and forced bundling.
Vue.js using TypeScript doesn't mean that you'll have to. You can continue to ignore it and enjoy using plain old JavaScript (albeit with more informative feedback in your IDE).
Also, you'll continue to be able to include Vue.js with a <SCRIPT> tag, as easily as you did jQuery.
This is helpful if you want to get some reassurance right from the source: https://www.youtube.com/watch?v=WLpLYhnGqPA
Vue.js using TypeScript doesn't mean that you'll have to. You can continue to ignore it and enjoy using plain old JavaScript (albeit with more informative feedback in your IDE).
Also, you'll continue to be able to include Vue.js with a <SCRIPT> tag, as easily as you did jQuery.
This is helpful if you want to get some reassurance right from the source: https://www.youtube.com/watch?v=WLpLYhnGqPA
I find myself agreeing in some ways. I had my hey-day on the frontend, enjoying all the new things being built for JS devs. Not just the big libraries like React or Vue, but others ones like Rx, Ramda, Lodash, and every other novel abstraction you can imagine. There's some really cool tech there but as a whole it's immature as hell.
My satisfaction as a software dev has increased massively since I've renewed my focus on the backend, and also spent some time with Java and other mature languages.
We still get things badly wrong but at least it's wrong in a way I can understand. I've looked at some new frontend projects and I would have to learn 7 or 8 different abstractions, inside a monorepo, just to understand how to build a simple interface to a collection of APIs.
Fuck that. The churn is too high and you might wonder how people built GUIs at all when you look at a modern web-app codebase.
My satisfaction as a software dev has increased massively since I've renewed my focus on the backend, and also spent some time with Java and other mature languages.
We still get things badly wrong but at least it's wrong in a way I can understand. I've looked at some new frontend projects and I would have to learn 7 or 8 different abstractions, inside a monorepo, just to understand how to build a simple interface to a collection of APIs.
Fuck that. The churn is too high and you might wonder how people built GUIs at all when you look at a modern web-app codebase.
Damn, you're right. I can't believe React took over and the jQuery project was shut down and barred from the web.
Oh wait. That didn't happen. What is preventing you from using only jQuery and "some" backend?
That's right. Just you.
Oh wait. That didn't happen. What is preventing you from using only jQuery and "some" backend?
That's right. Just you.
You're making the assumption everyone has the luxury of picking their stack or throwing away and rewriting their whole product. That isn't the case for a lot of developers.
What is preventing you from making that choice?
I've been waiting for something like that for ages.
Really, setting up and fixing js tooling breakage often take more time than actual development for smaller projects
Really, setting up and fixing js tooling breakage often take more time than actual development for smaller projects
Man you can already build web applications without bundlers! go with sqlite will give you a single binary you just run!
Also if your needs are simple you can just write a cgi script (provided you don't need too many RPS.)
Also if your needs are simple you can just write a cgi script (provided you don't need too many RPS.)
I'm not sure what this means… sqlite isn't available to use in any browser. Not to mention, it has nothing to do with JavaScript on the web.
Snowpack is for bundling ES modules to build web applications. Nothing mentioned in your comments works to build a client-side web application. If this your comment was some sly remark, it's totally lost on me.
Also, what's RPS?
Snowpack is for bundling ES modules to build web applications. Nothing mentioned in your comments works to build a client-side web application. If this your comment was some sly remark, it's totally lost on me.
Also, what's RPS?
The joys of the javascript ecosystem: (1) creating complex solutions for problems no one has or (2) creating complex solutions to fix the problem of complex solutions that didn't need to exist in the first place
It is an endless loop.
The first dot-com bubble resource wastefulness was spending so much money on networking gear. Every one had oversized expensive Cisco gear.
This dot-com bubble resource wastefulness is so many hundreds of thousands of engineering hours devoted to mega super over engineered Javascript solutions.
It is an endless loop.
The first dot-com bubble resource wastefulness was spending so much money on networking gear. Every one had oversized expensive Cisco gear.
This dot-com bubble resource wastefulness is so many hundreds of thousands of engineering hours devoted to mega super over engineered Javascript solutions.
I get framework and tooling fatigue, but it seems misaimed here. This project is an attempt at minimizing complexity, not adding onto it. There's a fundamental problem with writing JS for the browser: how do you expresses your dependencies?
jquery-era code solved this by just putting the dependencies in the README of a project (e.g. "this project requires jQuery and jQuery UI version 3! load them before loading this script!"). It worked, but it was error prone and manual.
More recent code has solved it by writing code that used abstract specifiers, like require('jquery'), which meant that you needed to use a complicated and often hyperconfigurable bundler to run in the browser (because the browser can't go searching the filesystem to figure out where the code for the 'jquery' package is)
With ES modules we're almost there, browsers can import files now, but they still need a bit of additional info to tell them how to resolve underspecified modules like 'jquery' (as opposed to './utils.js' which they can handle with no problem). You can write your code with fully specified imports, but the difficulty is that that code doesn't travel well, e.g. if you write `import '../node_modules/jquery/jquery.js'` that won't work if someone uses your package as a library, because jquery.js will actually be at '../jquery/jquery.js' because your package lives in the node_modules directory.
jquery-era code solved this by just putting the dependencies in the README of a project (e.g. "this project requires jQuery and jQuery UI version 3! load them before loading this script!"). It worked, but it was error prone and manual.
More recent code has solved it by writing code that used abstract specifiers, like require('jquery'), which meant that you needed to use a complicated and often hyperconfigurable bundler to run in the browser (because the browser can't go searching the filesystem to figure out where the code for the 'jquery' package is)
With ES modules we're almost there, browsers can import files now, but they still need a bit of additional info to tell them how to resolve underspecified modules like 'jquery' (as opposed to './utils.js' which they can handle with no problem). You can write your code with fully specified imports, but the difficulty is that that code doesn't travel well, e.g. if you write `import '../node_modules/jquery/jquery.js'` that won't work if someone uses your package as a library, because jquery.js will actually be at '../jquery/jquery.js' because your package lives in the node_modules directory.
> how do you expresses your dependencies?
because literally just putting them in a folder somehow became insufficient for any number of reasons, some of which seem to have to do with JS's lack of an include() function like every other interpreted language has had since forever
like, how about i don't need 20,000 dependancies, and just use an application stack that includes normal things like trimming a string
because literally just putting them in a folder somehow became insufficient for any number of reasons, some of which seem to have to do with JS's lack of an include() function like every other interpreted language has had since forever
like, how about i don't need 20,000 dependancies, and just use an application stack that includes normal things like trimming a string
> some of which seem to have to do with JS's lack of an include() function
This has been solved by ES Modules, which is already in all major browsers. Only IE is lagging behind (but there are polyfills).
This has been solved by ES Modules, which is already in all major browsers. Only IE is lagging behind (but there are polyfills).
> how do you expresses your dependencies?
By writing all code from scratch so that it doesn’t require any dependence’s from aging frameworks.
If everyone wrote their own kits then the web would be a more of a mature place.
Downvoted without any reasons? The web once before didn’t rely on frameworks.
PHPNuke wasn’t a framework.
PHPBB wasn’t a framework.
E107 wasn’t a framework.
If you wanted something. you coded it yourself.
/shrug
maybe it’s just me that feels the web is now polluted with Mb’s of wasted code. And even now it’s seen as bad practise not to use framework.
By writing all code from scratch so that it doesn’t require any dependence’s from aging frameworks.
If everyone wrote their own kits then the web would be a more of a mature place.
Downvoted without any reasons? The web once before didn’t rely on frameworks.
PHPNuke wasn’t a framework.
PHPBB wasn’t a framework.
E107 wasn’t a framework.
If you wanted something. you coded it yourself.
/shrug
maybe it’s just me that feels the web is now polluted with Mb’s of wasted code. And even now it’s seen as bad practise not to use framework.
> devoted to mega super over engineered Javascript solutions
Hey now, let's not discount the rise and fall of NoSQL, reinventing of data analysis except using python and spark cause SQL is too boring, or discovering linear regressions using a fleet of GPUs under the banner of Machine Learning!
It'll be nice when people get back to solving real business problems.
Hey now, let's not discount the rise and fall of NoSQL, reinventing of data analysis except using python and spark cause SQL is too boring, or discovering linear regressions using a fleet of GPUs under the banner of Machine Learning!
It'll be nice when people get back to solving real business problems.
Fall of NOSQL?
Is your shop still using it? Most NoSQL systems I've seen in the wild are pretty much just used as a caching store .. fancy Reddis really. All the big shops I've worked at still use Postgres for persistant storage. If they need speed; they'll add Elastic Search or Spark and have indexing services to make sure they stay up to date.
I think there are probably quite a lot of production Mongo databases out there from companies founded around the peak of the (bootcamp-driven) NoSQL hype train.
No one's bragging about it, probably everyone regrets it, and most companies will never practically be able to get off it (because, when your data is an unstructured mess it's a huge project to try and figure out how to get to structure, not to mention maintaining consistency during the migration. And you have that home-grown "relational" layer someone wrote for Mongo when they realised that they really did have relational data after all, and which is now coupled to everything...)
(If you thought I was describing the primary database at my day job, well...)
No one's bragging about it, probably everyone regrets it, and most companies will never practically be able to get off it (because, when your data is an unstructured mess it's a huge project to try and figure out how to get to structure, not to mention maintaining consistency during the migration. And you have that home-grown "relational" layer someone wrote for Mongo when they realised that they really did have relational data after all, and which is now coupled to everything...)
(If you thought I was describing the primary database at my day job, well...)
Most companies that adopted MongoDB at peak NoSQL either failed or were forced to switch to a better option (NoSQL or otherwise): that was a steaming pile of crap that couldn’t be trusted with data. The people behind it were concerned with marketing and going viral and succeeded at just that, it’s only recently that the money and time has been put into making the product itself actually any good.
Then perhaps we really are an outlier. That'd be nice: fewer people than I thought toiling under the yoke of a crappy database.
The post-IPO success of Mongodb Inc, and Amazon's recent roll out of their own compatible hosted solution makes me suspect not, though.
The post-IPO success of Mongodb Inc, and Amazon's recent roll out of their own compatible hosted solution makes me suspect not, though.
Perhaps I was a little too optimistic ;)
It’s not sexy but we use both Azure table storage and Amazon Redshift and they are nosql in my book.
Redshift is a columnar MPP fork of postgres, definitely not NoSQL. Do you mean DynamoDB?
[deleted]
I feel like many experienced developers I know have gone back to defaulting to SQL databases again, because it turns out the trade-offs of NoSQL (schema-free, horizontally-scaled-but-eventually-consistent etc) weren't worth the trade-offs.
But if it's the right tool for a FAANG company surely it must be the right tool for my use-case /s
Avoiding the FUD and "this vs. them" on posts like these is nearly impossible. Snowpack is an awesome utility and I'm glad it exits. In fact, Snowpack is a great compliment to Rollup for development - because Rollup <3 ES Modules.
I'm a core contributor on Rollup. Rollup is surging, and we've been seeing a ton of interest and new contributors. We're doing some awesome things to improve it, and if you'd like to help advance ES Modules and tooling, we'd love your help.
I'm a core contributor on Rollup. Rollup is surging, and we've been seeing a ton of interest and new contributors. We're doing some awesome things to improve it, and if you'd like to help advance ES Modules and tooling, we'd love your help.
It would have been great to see some replies from those who downvoted. I'm not sure how that message isn't positive, but it I'd welcome some outside perspective on that.
I thought this was going to be an article showing you how to build modern websites without the cancer that is /node_modules/ but it's Yet Another Webpack Killer. Imagine my face as I wince at the JS ecosystem as a whole.
This isn't really a webpack competitor, it's the same functionality of webpack (production-ready js builds) but leveraging modern web standards (ESM)
It's almost like comparing jQuery to web components, maybe you can achieve similar things to both, but one is a feature with native browser support.
It's almost like comparing jQuery to web components, maybe you can achieve similar things to both, but one is a feature with native browser support.
These tools aren't the simplest things, but so is everything, everywhere. Complexity needs to exist somewhere, and using an abstraction to hide them is something natural. Do people think we shouldn't use compilers because we 'can' write binary ELF files directly? Same goes to JS.