5 ms·

You can literally use Javascript for all of this.

by erlich 10y ago

meredydd 10y ago
I think you may be misunderstanding my point. If you have to invoke a brand new JS framework with limited uptake and many competitors, and "one of a million" CSS frameworks, in order to declare this problem solved, you are perpetuating the problem. I don't want to knock these tools too hard, because I can readily believe that (eg) Flow, or Typescript, or whatever we'll all be using next week, is much better than using vanilla JS/CSS. But the fact that we need to know all of Flow, and all of JS, and all of bootstrap, and all of CSS, and we're still not even off the client yet, is exactly why the web is a mess.
- erlich 10y ago
  My thinking on this is that everytime someone has tried to unify these tools it hasn't gone well. Think about Google Web Toolkit, or Microsoft's XAML. It's better to have everyone experimenting, blogging and doing their thing, and the best ideas rise to the top. 2015 was probably the worst time to be a web developer on a greenfield project. You had Angular deprecation and the Flux wars, and Babel 5 -> 6 migration. I do agree its a mess and a freaking nightmare most of the time. I've spent hundreds of hours setting my toolchain up and if something like webpack were to lose favour, I would be devastated. I think we are in need of a Rails for modern JS. My prediction is that we will see this emerge soon. A shift from project-templates to simple, generic plugin system. Webpack seems quite strong as the packager. Angular 2 CLI just migrated to webpack from Brocolli for example. React and Redux are standard now. And npm is the package manager of choice.
  - rpeden 10y ago
    Did GWT or XAML really try to unify things? Back in 2009, I worked on a complex SPA using GWT. With GWT, you could pretend to know nothing about HTML/CSS by just using the ugly build in components, but none of the GWT users I met did that. Our app used a Model-View-Presenter structure, dependency injection, and event bus for asynchronous communication to let components know when their data had updated, plus UIBinder templates for defining the look of components (which are mostly just HTML and CSS). So although it was nicely structured, it was very much a web app, and the development experience felt pretty comparable to what I experience in React today. XAML is mostly just a way to declaratively specify the layout and structure of UI components. Actually, I think it's just a declarative syntax for creating a hierarchy of object instances. If I remember correctly, the XAML and its corresponding C# file are both partial implementations of the same class, since .NET allows partial classes. Now, I'm not saying that I think the current state of JavaScript tooling is the worst thing ever. But I do think that that some of the 2009-2010 era JavaScript frameworks provided a more sane and cohesive development experience. React and Angular are nice, but I also remember that in 2010 it felt pretty neat to create an interface in OSX's Interface Builder, and have it show up in my browser exactly the way I'd drawn it.
    - erlich 10y ago
      The point I'm making is that when people have tried to develop a UI framework in a single language from scratch and offer the same functionality as the web, they fail. Performance sucks, or its not flexible enough to deliver certain functionality. By XAML I guess I mean WPF or whatever it is called. The bet was that Silverlight would be installed in every browser and you could build more powerful apps. I remember reading a post about how Evernote rewrote their WPF app because performance was never good enough. GWT tried to make a nicer API for building UIs. The API was nice, but I guess the whole transpilation caused issues with debugging etc. --- HTML, JS, CSS is evolving in such unpredictable ways, each time getting better and better. It just has such a large community using it and experimenting with it all the time - I don't think anyone can compete with the hive mind of web devs.
chx 10y ago
That leads to the MEAN stack (Mongo, Express, Angular, Node) and I am not so sure whether that's where the rosy future is.
- unclebucknasty 10y ago
  Exactly. Intuitively, I don't think the problem can be solved with the same "let's glue together a bunch of stuff and call it a stack" approach that got us here.
  - erlich 10y ago
    I'm hoping it is. We have ended up with really good tools compared to what we had before. Think about using commonjs requires, compared to the craziness of the Rails asset pipeline and sprockets, or manually specifying js files. We just need to standardize the glue...
    - unclebucknasty 10y ago
      Better bad is not the same as good. The approach itself yielded the issues such as that you reference, which have only been partially resolved by subsequent iterations of the same approach. I don't believe we should give credit for an approach that yields what is still a net-negative. It's a new thinking that we need, not reluctant acceptance of the best sub optimal execution the old thinking can deliver.
    - rpeden 10y ago
      The best part will be when we're all standardized on ES2015 modules instead of commonJS modules. I agree with you that CommonJS requires are nice to use, but since they're not statically analyzable the way ES2015 imports are, optimizing compilers like the Closure Compiler can't really analyze your entire application, including its dependencies. Once we've completely made the ES2015 transition (at least for front end modules), we might be in a position to see some really great front end tooling.
      - 10y ago
deleted 10y ago
[deleted]

You can literally use Javascript for all of this.

by erlich 10y ago

You can literally use Javascript for all of this.

I think you may be misunderstanding my point. If you have to invoke a brand new JS framework with limited uptake and many competitors, and "one of a million" CSS frameworks, in order to declare this problem solved, you are perpetuating the problem. I don't want to knock these tools too hard, because I can readily believe that (eg) Flow, or Typescript, or whatever we'll all be using next week, is much better than using vanilla JS/CSS. But the fact that we need to know all of Flow, and all of JS, and all of bootstrap, and all of CSS, and we're still not even off the client yet, is exactly why the web is a mess.

erlich 10y ago
My thinking on this is that everytime someone has tried to unify these tools it hasn't gone well. Think about Google Web Toolkit, or Microsoft's XAML. It's better to have everyone experimenting, blogging and doing their thing, and the best ideas rise to the top. 2015 was probably the worst time to be a web developer on a greenfield project. You had Angular deprecation and the Flux wars, and Babel 5 -> 6 migration. I do agree its a mess and a freaking nightmare most of the time. I've spent hundreds of hours setting my toolchain up and if something like webpack were to lose favour, I would be devastated. I think we are in need of a Rails for modern JS. My prediction is that we will see this emerge soon. A shift from project-templates to simple, generic plugin system. Webpack seems quite strong as the packager. Angular 2 CLI just migrated to webpack from Brocolli for example. React and Redux are standard now. And npm is the package manager of choice.
- rpeden 10y ago
  Did GWT or XAML really try to unify things? Back in 2009, I worked on a complex SPA using GWT. With GWT, you could pretend to know nothing about HTML/CSS by just using the ugly build in components, but none of the GWT users I met did that. Our app used a Model-View-Presenter structure, dependency injection, and event bus for asynchronous communication to let components know when their data had updated, plus UIBinder templates for defining the look of components (which are mostly just HTML and CSS). So although it was nicely structured, it was very much a web app, and the development experience felt pretty comparable to what I experience in React today. XAML is mostly just a way to declaratively specify the layout and structure of UI components. Actually, I think it's just a declarative syntax for creating a hierarchy of object instances. If I remember correctly, the XAML and its corresponding C# file are both partial implementations of the same class, since .NET allows partial classes. Now, I'm not saying that I think the current state of JavaScript tooling is the worst thing ever. But I do think that that some of the 2009-2010 era JavaScript frameworks provided a more sane and cohesive development experience. React and Angular are nice, but I also remember that in 2010 it felt pretty neat to create an interface in OSX's Interface Builder, and have it show up in my browser exactly the way I'd drawn it.
  - erlich 10y ago
    The point I'm making is that when people have tried to develop a UI framework in a single language from scratch and offer the same functionality as the web, they fail. Performance sucks, or its not flexible enough to deliver certain functionality. By XAML I guess I mean WPF or whatever it is called. The bet was that Silverlight would be installed in every browser and you could build more powerful apps. I remember reading a post about how Evernote rewrote their WPF app because performance was never good enough. GWT tried to make a nicer API for building UIs. The API was nice, but I guess the whole transpilation caused issues with debugging etc. --- HTML, JS, CSS is evolving in such unpredictable ways, each time getting better and better. It just has such a large community using it and experimenting with it all the time - I don't think anyone can compete with the hive mind of web devs.

chx 10y ago

That leads to the MEAN stack (Mongo, Express, Angular, Node) and I am not so sure whether that's where the rosy future is.

unclebucknasty 10y ago
Exactly. Intuitively, I don't think the problem can be solved with the same "let's glue together a bunch of stuff and call it a stack" approach that got us here.
- erlich 10y ago
  I'm hoping it is. We have ended up with really good tools compared to what we had before. Think about using commonjs requires, compared to the craziness of the Rails asset pipeline and sprockets, or manually specifying js files. We just need to standardize the glue...
  - unclebucknasty 10y ago
    Better bad is not the same as good. The approach itself yielded the issues such as that you reference, which have only been partially resolved by subsequent iterations of the same approach. I don't believe we should give credit for an approach that yields what is still a net-negative. It's a new thinking that we need, not reluctant acceptance of the best sub optimal execution the old thinking can deliver.
  - rpeden 10y ago
    The best part will be when we're all standardized on ES2015 modules instead of commonJS modules. I agree with you that CommonJS requires are nice to use, but since they're not statically analyzable the way ES2015 imports are, optimizing compilers like the Closure Compiler can't really analyze your entire application, including its dependencies. Once we've completely made the ES2015 transition (at least for front end modules), we might be in a position to see some really great front end tooling.
    - 10y ago

deleted 10y ago

[deleted]